软件架构发展历程分享

设计文档和代码

我们一般说的架构既包括架构的设计过程，也包括设计的产出物，一般可以包括各类设计文档、设计图，也可以包括一些技术验证代码、Demo 或者其他相关程序。文档的目的在于准确记录我们的思维产物，在软件尚未实现时，作为指导蓝图，尽量精确的描述清楚软件。

在软件的实现过程中，可能随时随着我们的深入研究，根据具体情况对文档做出局部的一些调整和修改。文档作为结项或交接的一部分，也是整个软件项目的产出物的一部分，成为公司 IT 资产的有机组成部分。

架构服务于业务

正如19世纪的伟大建筑师路易斯•沙利文（LouisSullivan）倡导的建筑设计著名格言：“功能决定形式（Form follows function）”，软件架构首先是要服务于业务功能的。

架构影响研发团队的组织形式

业务拆分的方法和技术框架的选择必然会影响到研发团队的组织形式。业务拆分的越细致，越有利于我们更好的对项目的各项指标量化计算，更精确的估计工时和成本，从而指导我们每个小组应该分配多少资源，使用什么样的协同和任务确认形式。

并且随着项目的推进，计划与实际情况之间的匹配程度也随时可以进一步精确调整，进而影响到我们应该对每一块任务的投入资源进行动态调整。

架构存在于每一个系统

每一个已经实现并运行的系统，都是特定架构设计的载体。有些系统对应的架构，有详细的设计文档来描述；有些系统的设计文档，残缺不全，甚至还因为在系统的发展变化的同时，文档没有更新，导致设计文档与实际系统不符；有些系统干脆就没有设计文档。但是这些系统，都是基于一定的架构来创建的。

每种架构都有特定的架构风格

每种架构方式，每个具体系统内所体现的架构设计，都是可以被工程师们理解，进而提炼出来一些架构思想和设计原则，这些思想和原则就是这种架构方式的风格。依据这些风格，我们可以将各种架构方式，进行分门别类，从而进一步讨论每种架构风格的特点。

架构需要不断的发展演进

随着计算机软硬件的不断发展，软件架构思想也在不断的发展变化。另一方面，软件为其提供业务处理和服务能力的每个具体行业领域也在不断发展变化，业务处理流程、参与角色、业务形式不断的推陈出新。

这就要求我们在系统架构设计时，保持终身学习的精神，持续吸收新思想新知识，保持贴近一线业务群体，随时因地制宜，调整架构设计，采取最适合当下场景的解决方案。

架构的目标与方法

明确软件系统架构的一些通用目标，可以使我们更明确如何考虑架构的方向；而了解架构的方法和方法论，则让我们可以知道从哪些角度可以比较全面的描述清楚一个系统的架构设计。

可控性与拆分

对于复杂问题的简化处理，一个简单办法就是分而治之。按一定的粒度把目标问题进行分解，可以非常有效的提升目标的可控性，使得目标变得更加可以量化、进而优化。

系统按照合适的粒度拆分成不同模块的过程，我们一般称为模块化。模块化也是软件工程化的基础。在这个基础上才能够实现分工合作。

复用性与抽象

复用性一直是软件设计领域的一个很重要的指标。复用的一个关键是我们对于现有具体问题的抽象，找到各种不同问题中存在的不变性，进而作为一种通用结构来统一处理。

拆成是把整体变成很多局部，再对局部分开对待和研究其性质。反过来，我们按照高内聚的指导思想把一些紧密联系的功能聚合后，打包成一个可以整体复用的部分，这就是组件，这个过程就是组件化。

通过组件化，我们可以得到抽象再组合出来很多业务组件。这样，在更大粒度上实现了功能的复用。

非功能性需求九维目标

（1）高性能

系统必须满足预期的性能目标，在并发用户数（Concurrent Users）、并发事务数（Transactions per Second，TPS）、吞吐量（Throughout）等指标方面达到预估值，支撑使用人群的正常使用操作。

（2）可靠性

业务系统直接影响到用户的经营和管理，因此必须是可靠的。

（3）稳定性

软件系统必须是能够在用户的使用周期内长期稳定运行的。这要求系统具有一定的容错能力。

（4）可用性

可用性是指系统在指定时间内的提供服务能力的概率值。我们一般采取集群、分布式等手段提升系统的可用性。高可用性是目前系统架构设计方面的一个热点。

（5）安全性

用户的业务数据是具有非常高的商业价值，如果被泄露或篡改将会带来重大损失。安全性是软件系统的一个重要的指标，也是架构设计的一个重要目标。

（6）灵活性

软件系统应该具备满足不同特点的用户群和目标市场的能力，更灵活。

（7）易用性

软件系统必须拥有较好的用户体验，便于用户使用。

（8）可扩展性

业务和技术都在不断的发展变化，软件系统需要随时根据变化扩展改造的能力。

（9）可维护性

软件系统的维护包括修复现有的错误，以及将新的需求和改进添加到已有系统。因此一个易于维护的系统对于用户提出的问题或改进，可以及时的实现高效的反馈和响应支持，同时有效降低维护成本。

基于这些目标，经常有人说：“架构是系统非功能性需求的解决办法的集合”。

作者说：

本文原文以架构发展历程为镜子，借鉴历史，以便更好的了解现在，迈向未来。

面向广大一线程序员、架构师、技术经理，我们从研发管理和技术管理等方面，阐述每种架构的传承与改进，结合背后的架构思想和设计逻辑的变迁，全部浓缩到这里：

1. 理解什么是架构，模式、服务、组件、模块、框架、平台等概念及其关系，日常工作中更精确的使用这些概念表述自己的架构设计。
2. 熟悉架构的目的、形式、方法，从而能够以全面的架构师思维，全面和科学地思考系统设计，结合自己的实践，逐步成为一名合格的架构师。
3. 了解软件架构发展过程，从单体架构，到分层模式架构，集群架构，分布式架构、SOA 架构、微服务架构（MSA）等，能够深刻认识其中的架构思想。
4. 掌握各种架构风格的特点和方式，以及实践过程中的优缺点，能够在具体的架构设计中灵活应用实践各种架构思想。