什么是架构？
1 架构定义
架构，在汉语词典里的意思是：
人们对一个结构内的元素及元素间关系的一种主观映射的产物。
由此可见，万物皆可谈架构。不管是软件、飞机还是建筑，只要人们主观地对其进行分解和组装，就已经运用了架构的概念。
实际上，架构起源于建筑领域。充满智慧的古代劳动人民将复杂的建筑按其特点分解为一个个具有共性的结构构件和建筑构件。仔细想想，楼面、墙体、柱子、地基，和软件工程中的MVC是不是如出一辙？
既然架构是人主观设计的，就必然有好坏之分。
好的架构设计，如赵州桥。虽为石板所铸，屹立千年不倒。
坏的架构设计，如美国的塔科马海峡大桥。耗资近千万美元，却在建成4月后被微风吹塌。
2 架构本质
架构的本质是关注点分离。
这种系统思维方法可以追溯到柏拉图时期，与“庖丁解牛”思路相近。具体做法是先将复杂问题做合理的分解，将问题的各个关注点分而治之，再进行组合，最终形成整体的解决方案。
软件架构设计应该按照其业务特点来将软件本身划分成不同的部分，将变化点错落有致地封装到软件系统的不同部分，从而降低耦合性。这样即使面对变化，也能清晰地识别变化点，将影响最小化。
3 架构视图
3.1 企业架构
架构视图五花八门，但是是分层的，目前常见的是从企业架构说起。企业架构处于战略层面，是架构的最顶层，自顶向下能更简洁明了地看清各种架构视图间的层次关系。
企业架构（Enterprise Architecture，EA），是基于业务导向和驱动的架构来理解、分析、设计、构建、集成、扩展、运行和管理信息系统。将跨企业的、常为零散的那些遗留流程优化进一个集成的环境，及时响应变更并有效的支持业务战略的交付，辅助企业完成业务及IT战略规划。
主要的企业架构框架为Zachman、EAP、TOGAF、FEA、DoDAF这五种：
其中，最主流的是 TOGAF（开放组体系结构框架）。从TOGAF中，我们能看到再熟悉不过的业务架构、系统架构和技术架构。
业务架构、系统架构和技术架构往往会一同出现，因为他们是一个层面上的概念。
3.2 业务架构
业务架构是企业的蓝图，它提供了对组织的共识并用于对齐战略目标和战术要求。关注点在于业务需求，是把企业的业务战略转化为日常运作的渠道。独立于技术而关注业务能力、流程和产品是非常重要的，这是与业务相关的架构视角分析。
业务架构可以分为战略业务架构和运营业务架构，包括业务的组织结构、企业目标和目标、业务功能、商业服务、业务流程、业务角色、业务数据模型、组织和职能的相关性等。设计过程中主要考虑业务平台化、核心业务与非核心业务剥离、主辅流程区分、不同类型业务隔离。
3.3 系统架构
系统架构是顺接业务转向IT的重要架构，关注点在于系统的应用和数据架构问题。由应用架构和数据架构构成。
这一阶段需要开发基准和信息系统架构，进行支持已有架构视图的缺口分析，架构信息系统服务，并将它们与业务服务相关联。
系统架构的表现形式通常就是线框图，它的目的是将系统分解成多个独立的子系统，本质上是遵循分而治之的理念。
3.4 技术架构
技术架构，关注点在于架构所需的基础设施（例如硬件和通讯）以及平台、中间件。可以粗略地认为技术架构由软件架构与基础架构组成。
技术架构定义了实现系统所需的各种技术，包括开发类、过程管理类、运行环境类、运维支撑类、以及相关技术规范等，描述了应用、应用平台、基础设施等技术组件与信息系统间的关系。
3.5 应用架构
应用架构，关注点是IT系统、功能模块的统一规划、架构标准/原则、边界划分和关联关系。
应用架构向上承接了企业战略发展方向和业务模式，向下规划和指导企业各个IT系统的定位和功能。包括了应用系统服务、逻辑应用组件、物理应用组件、应用分布、应用共享、应用集成、应用管理原则等。
3.6 数据架构
数据架构，关注点是持久化数据的组织、数据传递、数据转换和数据存储策略。
数据架构，包括业务数据模型、逻辑数据模型、物理数据模型、数据编码规范、数据管理流程模型、数据实体/业务功能矩阵、与选定观点相对应的数据架构视图等。
数据架构解决数据持久化和存储层面的问题，包括数据的分布、复制、同步等。具体表现为确定要存储的数据，可以是文件、关系数据库、实时数据库等；确定存储格式，包括文件格式、数据库图表等；确定需要的数据库；保障数据存储层面的性能、高可用性、灾备等。
3.7 基础架构
基础架构，关注点在于系统运行所需的基础设施。
基础架构是指企业IT环境存在、运行和管理所需的硬件、软件、网络资源和服务的组合。它允许组织向其员工、合作伙伴和/或客户提供It解决方案和服务，通常是组织内部的，并部署在自有设施中。
3.8 软件架构
软件架构，关注点是软件系统中元件之间的关系。
软件架构是对软件系统运行时元素的抽象，定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑和流程。可以粗略地认为软件架构由逻辑架构、开发架构、运行架构组成。
3.9 部署架构
部署架构，关注点是软件如何部署。举例来说可以将所有的软件模块放在一台WEB服务器上，也可以用微服务的方式部署在不同的服务器上，当然缓存、数据库、文件服务器等都可以独立部署。
从这个角度讲，部署架构是将在逻辑架构上拆分出来的组件（或模块）是如何分解到基础架构不同的物理设备上的。
3.10 逻辑架构
逻辑架构，关注点是功能需求，是行为和职责的划分。
逻辑架构包含用户直接可见的功能，还有系统中隐含的功能。并明确其与协作关系；其中职责的划分注意逻辑的分层、子系统以及关键类的定义；协作的定义关注接口的定义与协作关系的明确。
3.11 开发架构
开发架构，关注点是程序源代码，配置文件、编译后的目标文件和第三方库文件等软件模块实际组织方式。着重考虑开发期质量属性，包括可扩展性、可重用性、可移植性、易理解性、易测试性。
不仅仅是应用程序本身，还包括应用程序依赖的SDK、第三方类库、中间价等。尤其是像目前主流的Java、.NET等依靠虚拟机的语言和平台，以及主流的基于数据库的应用，和逻辑架构有紧密的关联。
开发架构的目的是确定程序单元以及程序单元的组织结构；其中程序单元包括源文件、配置文件、程序库、框架、目标单元；程序单元组织包括project划分、project目录结构、编译依赖关系。
3.12 运行架构
运行架构，关注点是系统的并发和同步，涉及进程和线程等技术。着重考虑运行期质量属性——性能、可伸缩性、持续可用性、安全性。
顾名思义，更关注的是应用程序运行中可能出现的一些问题。例如并发带来的问题，比较常见的“线程同步”问题、死锁问题、对象创建和销毁（生命周期管理）问题等等。开发架构，更关注的是飞机起飞之前的一些准备工作，在静止状态下就能规划好做好的，而运行架构，更多考虑的是飞机起飞之后可能发生的一些问题。
运行架构的目的是确定控制流和控制流的组织；其中控制流包括进程、线程、服务程序；控制流组织包括系统的启动与停机、控制流通讯、同步与加锁。
3.13 安全架构
安全架构，关注点是解决特定场景或环境中涉及的必要性和潜在风险。着重考虑主机、网络、应用、数据的风险识别、安全检测、安全防御、安全响应、安全恢复等。
安全架构是企业架构中，业务架构、系统架构、技术架构之外的重要一环，是一种围绕着信息系统架构的安全性而统一展开的安全设计工作，是一种为决策过程定义规则的方法，它使用安全框架来提供在给定用例中必须使用的安全控制组件。
4 架构原则
在架构设计的过程中，除了需要考虑成本、可用性、可扩展性等要素外，还有许多需要遵循的原则。
4.1 高内聚
Common Closure Principle（CCP）–共同封闭原则
包中的所有类对于同一类性质的变化应该是共同封闭的。
The Release Reuse Equivalency Principle (REP) –重用发布等价原则
重用的粒度就是发布的粒度。
Common Reuse Principle (CRP) –共同重用原则
一个包中的所有类应该是共同重用的。
4.2 低耦合
The Stable Dependencies Principle (SDP) –稳定依赖原则
包之间的依赖关系都应该是稳定方向依赖的，包要依赖的包要比自己更具有稳定性。
Acyclic Dependencies Principle (ADP) –无环依赖原则
在包的依赖关系图中不允许存在环。
Stable Abstractions Principle (SAP) –稳定抽象原则
包的抽象程度应该和其稳定程度一致。
4.3 其他原则
KISS原则：
Keep it simple, Stupid!
把一个产品做得连白痴都会用！
DRY原则：
Don’t Repeat Yourself
编程过程中不写重复代码,将能够公共的部分抽象出来,封装成工具类或者用
SOLID原则：
Single Responsibility Principle (SRP) –职责单一原则
一个类应该只有一个发生变化的原因。
Open/Closed Principle (OCP) –开闭原则
一个软件实体，如类、模块和函数应该对扩展开放，对修改关闭。
Liskov substitution principle (LSP) –里氏代换原则
所有引用基类的地方必须能透明地使用其子类的对象。
Interface Segregation Principle (ISP) –接口隔离原则
1、客户端不应该依赖它不需要的接口。
2、类间的依赖关系应该建立在最小的接口上。
Dependency Inversion Principle (DIP) –依赖倒置原则
1、上层模块不应该依赖底层模块，它们都应该依赖于抽象。
2、抽象不应该依赖于细节，细节应该依赖于抽象。
5 架构设计方法
按照关注点分离的原则，架构方法的核心是分而治之。
比如可以按大小粒度将系统分解为子系统再分解为模块最后分解为对应的类；按数据展示、加工、管理的不同职责划分将系统划分为展现层、业务层、数据层；按技术通用性，分离出特定应用部分、领域通用部分、技术通用部分。
5.1 边界划分
根据职责分离原则、通用专用分离原则、技能分离原则、工作量均衡原则，考虑到原则的决定性以及影响性，对系统进行边界划分，确定分层的细化、机制的提取、分区的引入。
5.2 架构分解
按照业务域、业务功能域、技术域以及涉众域对进行架构分解。
5.3 伸缩立方体
X轴伸缩——通过克隆，比如复制许多系统且负载均衡。
Y轴伸缩——通过划分不同职能或服务，比如微服务划分。
Z轴伸缩——通过划分相同事物，比如根据用户进行数据库分区。
伸缩样例：
6 架构风格和约束
软件架构风格众多，常见的有CQRS/LMAX、REST、SOA、B/S,C/S,三层架构、面向对象/响应式、EDA、DDD等。架构师应该根据系统的安全、可靠、性能、高可用、扩展性、易用性、可测试性方面的需要，选择合适的架构风格。
6.1 分层架构
优点：
- 结构简单，容易理解和开发。
- 层与层之间耦合度低，可以分层测试，其他层的接口可以模拟解决。
- 可以按层进行分解工作任务到不同开发小组。
缺点：
- 分层数量越多，调试团难，性能会有影响。
- 业务复杂，分层团难，业务逻辑变化，分层划分会发生变化。
- 扩展性差，用户请求量增加，需要扩展所有层，不能按需扩展。
6.2 事件驱动架构
优点：
- 分布式的异步架构，事件处理器之间高度解耦，软件的扩展性好。
- 基于事件的异步实现非阻塞请求，提高系统并发。
- 事件处理器可以独立地加载和卸载，容易部署。
缺点：
- 编程模型复杂，涉及异步编程和事务补偿。
- 难以支持原子性操作，因为事件通过会涉及多个处理器，很难回滚。
- 分布式和异步特性导致这个架构较难测试。
- 必须检测并忽略重复事件。
6.3 LMAX架构
优点：
- 基于Disruptor实现高并发，单线程能每秒处理6百万订单。
- 通过Ring Buffer提出新的并发模型，无锁免争用。
- 常驻内存的Business Logic Processor（DDD领域模型）在内存中处理业务逻辑。
- 可以通过事件回溯重新得到业务对象。
缺点：
- 需要提前配置完成任务所需的线程数。
- DDD建模有一定复杂度，设计工作量大。
- 异步编程，编程难度大，测试和调试团难。
- 架构比较小众，学习曲线陡。适合于低延迟，高并发。
6.4 微服务架构
优点：
- 扩展性好，模块和服务松耦合。
- 易部署，每个服务都是可部署单元。
- 易开发，每个服务都可以进行持续开发，持续集成，持续测试和部署。
- 易测试，可以单独测试每一个服务。
缺点：
- 如果按单一职责拆分服务，会导致系统产生大量的微服务，管理团难。
- 突现分布式问题如数据一致性，实时性，数据一致性。
- 服务之间依赖关系的管理，以及多版本之间的路由，让服务治理和监控变得复杂
7 架构演进
架构中唯一不变的就是变化。适合当前业务需求的架构才是好的架构。笔者之前负责的电商系统，就一直处于不断演进之中。
一开始为了快速试错响应业务，软件架构用的是基于PHP的MVC框架，成本较低，管理简单，开发速度一流。
后来访问量上去了，考虑到PHP的性能存在一定瓶颈，优化成本较高，且弱类型语言后续开发较难管理，决定将Model层的后端服务抽离出来，改为PHP基于hessian调用java的RPC架构，打造后续继续深化改造的基础。
改造后java应用多了，不可避免的就要面对管理的问题。于是引入了阿里的dubbo框架及相应的服务注册、配置中心、监控中心，将应用的不同功能单元进行服务拆分，并制定了技术规范、管理规范和服务间的调用规范。除了没用ESB，基本就是一套SOA架构了。
最后，随着业务领域的不断扩张，为了更快速地面对变化，根据业务进行了更彻底的去中心化、组件化和服务化。比如对数据库也进行了拆分，引入了DDD领域建模和DevOps思想，甚至连团队划分也进行了调整，使各服务真正可以独立开发、设计、运行。这时，一套完整的微服务架构就成型了。
参考资料
1.《软件架构设计》
2.《软件架构入门》
3.《The Art of Scalability》
4. 百度百科-企业架构
5. 百度图片