关于架构优化和设计,架构师必须知道的事情.docxVIP

概述你可以叫它SOA的新玩法、微服务、或者任意其它酷炫的名字。近几年来随着互联网的飞速发展，新的架构实践方式不断涌现，但是有一件事情是永恒不变的，那就是－“架构之道”；关于如何设计出灵活、高可用性以及能够快速适应变化的系统架构，我们依旧还有很大的发挥空间。本文会介绍关于如何构建前沿的、易维护的、安全的架构的几个要点，同时你也可以把它当作系统设计的准则或者用它来验证现有的架构是否合理。 就像我们经常所说的：没有最好的架构，只有最合适的架构。一个好的架构师，可以根据具体的需求、所拥有的资源等因素综合考虑而设计出最优的架构方案。特别是现在，业务的飞速变化、数据无处不在等这些因素的影响下，技术和框架也需要在变化的过程中不断地打磨和提升以适应新的业务需要。可能当时是最好的架构，但是后来我们还是要跟着业务的变化去做改进。这并不是一件坏事情，我们只要做好应对变化的准备即可。 与代码无关架构师这个词的意义非常广泛，有些架构师是指在公司负责编写软件的某些模块的人。当然多数公司并没有这样的职位，他们会有一些技术leader来负责具体的功能。我们这里所要讲的架构师不会太过于关注代码的细节，而是更关注系统各个模块之间如何协同、交互等一些更全局的一些事情。他们主要关注一些可能经常会被人遗忘但是又会为系统带来恶劣影响的部分，职责是确保所有的功能都能够以较好的质量及时被交付。这种人对于软件产品的成功有着举足轻重的地位，当然他们往往在一个公司里面可能同时负责好几个项目。 软件的架构至关重要，仅仅有较好的代码来完成功能不足以成为一个优秀的解决方案。因为它不仅仅涉及到代码，还有我们所写的各个模块之间如果交互和集成、数据如何存储、我们怎么样来进行开发和测试、以及在引进变动的时候的难易程度等等。在集成阶段，复杂性开始显现出来，和最开始的目标无关，最终整个设计是否足够灵活、可调整、以及模块化起着至关重要的作用。 这些事情都是和编写代码无关，但是需要我们来花时间考虑， 并且是整个系统最后是否成功的决定性因素。 要去考虑的细节还有一些原则比如：模块化、轻耦合、无共享架构；减少各个组件之前的依懒、注意服务之间依懒所有造成的链式失败及影响等。 DDD给我们提供了在不同的特定领域上下文以及业务功能的基础上拆分组件的指导方法。 把服务独立出来提供特定的功能，同时方便在应对变化的时候能够不影响其它的服务。 在大多数情况下，如果需要同步更新很多个服务则说明系统的耦合还不够低。当然，再完美的原则也会有例外的时候。比如当你想把系统部署在一些IoT设备上的时候，你可能要一次性部署所有的组件。这是允许的，但是，请尽量考虑服务之间的耦合及灵活性以应对将系统部署在不同平台上的需求。 即便如此，我们也不可能完全避免耦合，它总是会出现在某些场景下。这就需要我们提取一些抽象层将服务之间的交互定在契约上来避免复杂，提升灵活性。 这就需要我们有一种辨别能力，能够找到那些必须放在一起来做处理而不能拆解的功能。如果这些功能是值得放在一起的，那我们就可以将它独立成一个微服务，遵循高聚合的设计原因。 我们要记住的是，系统的设计要做到比较容易地增加或者修改原来的组件。无状态的架构是系统高扩展性的基石。 特别需要注意服务和组件之间如何交互，了解不同的协议的优缺点，包括速度以及可用性，来帮助我们来决定哪一种是最适合我们的。 基础设施、配置、测试、开发、运维为配置管理定义策略，因为同时发生的配置变化对系统所有造成的影响也是很重要的，所以需要由全局层面的的自动化更新方案来完成。 在如今，对于一个数据敏感的大型解决方案来说如果没有自动化的一些基础设施和稳固的开发、测试和部署流程，那就和自杀无异。我们需要花费一定时间来计划和准备开发、测试、生产环境，可能还需要一些额外的环境以备不时之需。 测试流程和策略也是非常重要的。一些最佳实践使用Blue-Green开发、金丝雀部署、A/B测试等。尽量保持测试环境与生产环境是一致的，至少硬件结构上来说应该是一样的。一定要做压力和负载测试，并且尽可能快的在生产上进行这样的测试，这样能够更快速、精确的帮我们找到线上的问题。 可调整的架构同时也意味着服务要可以被灵活独立的部署以及简单的基础运维操作。 利用不可变基础设施的优势。不可变基础架构，就是说系统一旦部署，就不再更变升级。当服务/应用需要升级时，只要部署一个新版系统，摧毁旧版就好了。在这个过程中，系统对外服务是几乎是持续的。（译者注） 保证打包/持续集成进程是基于统一的途径，并且不会对正在运行的服务进行任何更改（比如 禁用ssh），所有的更新都应该通过定义好的自动化配置和打包操作将它们应用到所有的对应的系统上，来避免配置遗漏。比如手工某个环境上修改配置，可能会漏掉其它环境的配置。 开发团队不应该过度关注基础设施，因为有一天可能基础设施也会