架构深入探讨

架构的本质

道是事物发展的本质规律，术是事物发展的具体途径。规律只有一个，途径很多，条条大路通罗马，罗马是道，大路是术。道为本，术为途，如果事先知道罗马在哪里，那么遍地是路，路路相通。架构也是如此，如果能领悟架构的本质，就不会拘泥于现有的实践和理论框框，而以最直接的方式解决问题，无招胜有招。

架构的三要素：

   1.职责明确的模块或者组件
   2.组件间明确的关联关系
   3.约束和指导原则


一个软件系统随着功能越来越多，调用量急剧增长，整个系统逐渐碎片化，越来越无序，最终无法维护和扩展，所以系统在一段时间的野蛮生长后，也需要及时干预，避免越来越无序。

那架构是如何实现无序到有序的呢？ 基本的手段就是分和合，先把系统打散，然后重新组合。

分的过程是把系统拆分为各个子系统/模块/组件，拆的时候，首先要解决每个组件的定位问题，然后才能划分彼此的边界，实现合理的拆分。合就是根据最终要求，把各个分离的组件有机整合在一起，相对来说，第一步的拆分更难。

拆分的结果使开发人员能够做到业务聚焦、技能聚焦，实现开发敏捷，合的结果是系统变得柔性，可以因需而变，实现业务敏捷。

架构师从境界上由浅到深可以分为四层：第一看山不是山，第二看山是山，第三看山不是山，第四看山是山。

刚接手项目时，对业务不了解，时时被业务方冒出的术语弄得一愣一愣的，如果把现有问题比作山，则是横看成岭侧成峰，根本摸不透，此时看山不是山。

经过业务梳理和对系统深入了解，可以设计出一个屌丝的方案，把各个系统串起来，解决当前的问题，对当前这个山能够看清楚全貌，此时能够做到看山是山。

通过进一步抽象，发现问题的本质，原来这个问题是共性的，后续还会有很多类似问题。设计上进行总结和升华，得出一个通用的方案，不光能解决当前的问题，还可以解决潜在的问题。此时看到的已经是问题本质，看山不是山。

最后回到问题本身，去除过度的抽象，给出的设计简洁明了，增之一分嫌肥，减之一分嫌瘦，既解决当前问题，又保留最基本的扩展，此时问题还是那个问题，山还是那个山。

第一境界给不出合适方案，不表。

第二境界的方案只解决表面问题，往往设计不够，碰到其它类似问题或者问题稍微变形，系统需要重新做。

第三境界的方案往往过度设计，太追求通用化会创造出过多抽象，生造概念，理解和实现均困难，此时系统的无序度反而增加，过犹不及。

第四境界的方案，在了解问题本质的基础上，同时考虑现状，评估未来，不多做，不少做。

佛教讲空和色，色即事物现象，空即事物本质，从这个意义上说，第一重境界无色无空，第二重境界过色，第三重境界过空，第四重境界站在色和空之间，既色又空，不执着于当前，不虚无于未来。

不空不色，既空既色，道法自然，本性如来，架构之髓也。


架构方案落地

架构分而治之的两种方式：

分而治之的缘由：问题太复杂了，超出了人们能够“一蹴而就”的范围。（接口和实现分离）

一、先不把问题研究得那么深，那么细，浅尝辄止，见好就收。这种分而治之的方式称为“按问题深度分而治之”。

二、先不研究整个问题，而是研究问题的一部分，分割问题。这种分而治之的方式称为“按问题广度分而治之”。（比如展现层、业务层和数据层的开发）



无架构，不系统，架构是大型系统的关键。从形上看，架构是系统的骨架，支撑和链接各个部分；从神上看，架构是系统的灵魂，深刻体现业务本质。

架构可细分为业务架构、应用架构、技术架构，业务架构是战略，应用架构是战术，技术架构是装备。其中应用架构承上启下，一方面承接业务架构的落地，另一方面影响技术选型。

如何针对当前需求，选择合适的应用架构，如何面向未来，保证架构平滑过渡，这个是软件开发者，特别是架构师，都需要深入思考的问题。

应用架构本质：

应用作为独立可部署的单元，为系统划分了明确的边界，深刻影响系统功能组织、代码开发、部署和运维等各方面，应用架构定义系统有哪些应用、以及应用之间如何分工和合作。

分有两种方式，一种是水平分，按照功能处理顺序划分应用，比如把系统分为web前端/中间服务/后台任务，这是面向业务深度的划分。另一种是垂直分，按照不同的业务类型划分应用，比如进销存系统可以划分为三个独立的应用，这是面向业务广度的划分。

应用的合反映应用之间如何协作，共同完成复杂的业务case，主要体现在应用之间的通讯机制和数据格式，通讯机制可以是同步调用/异步消息/共享DB访问等，数据格式可以是文本/XML/JSON/二进制等。

应用的分偏向于业务，反映业务架构，应用的合偏向于技术，影响技术架构。分降低了业务复杂度，系统更有序，合增加了技术复杂度，系统更无序。

应用架构的本质是通过系统拆分，平衡业务和技术复杂性，保证系统形散神不散。

系统采用什么样的应用架构，受业务复杂性影响，包括企业发展阶段和业务特点；同时受技术复杂性影响，包括IT技术发展阶段和内部技术人员水平。业务复杂性（包括业务量大）必然带来技术复杂性，应用架构目标是解决业务复杂性的同时，避免技术太复杂，确保业务架构落地。

常见的应用架构有多种，下面根据系统拆分方式，以及如何平衡业务与技术的角度进行分析，讨论各自的适用性，给企业应用架构选型提供参考。


1.单体式应用

系统只有一个应用，相应地，代码放在一个工程里管理；打包成一个应用；部署在一台机器；在一个DB里存储数据。单体式应用的架构如下图所示：





单体式应用采用分层架构，按照调用顺序，从上到下一般为表示层、业务层、数据访问层、DB层，表示层负责用户体验，业务层负责业务逻辑，数据访问层负责DB层的数据存取。

单体应用在水平方向上，上下层之间职责划分清晰；但垂直方向上缺乏清晰的边界，上下层模块之间是多对多的依赖关系，比如业务模块1 （图中BO1）可能调用数据层所有模块DAO 1~3， DAO1也可能被业务层所有模块BO1~3调用。

单体应用通过水平分层，降低了业务复杂性；同时模块之间是进程内部调用，技术实现简单。
但单体应用对系统的切分不彻底，只有水平切分，并且是逻辑上，因此适合业务比较单一，但深度上比较复杂的系统，比如TCP/IP网络通讯，从应用层/传输层/网络层/链路层，层层推进，类似这样的系统可以方便地增加水平层次去适配。

对于广度上复杂的业务，由于缺乏垂直切分，强行把不同业务绑定在一起，整个系统神散形不散，带来一系列问题。比如OTA网站包含机票/酒店/旅游等多个垂直业务板块，每块都比较独立，就不适合放在一起开发维护。

单体式应用的优点和缺点都很鲜明，如下图所示：




优点：
    现有IDE都是集成开发环境，非常适合单体式应用，开发、编译、调试一站式搞定
    一个应用包含所有功能，容易测试和部署
    运行在一个物理节点，环境单一，运行稳定，故障恢复简单

缺点：
    业务边界模糊，模块职责不清晰，当系统逐渐变大，代码依赖复杂，难以维护
    所有人同时在一个工程上开发，容易发生代码修改冲突，依赖复杂导致项目协调困难，并且局部修改影响不可知，需要全覆盖测试，需要重新部署，难以支持大团队并行开发
    当系统很大时，编译和部署耗时
    应用水平扩展难，一方面状态在应用内部管理，无法透明路由；另一方面，不同模块对资源需求差异大，当业务量增大时，一视同仁地为所有模块增加机器导致硬件浪费


2.分布式架构应用

在分布式应用架构中，应用相互独立，每个应用代码独立开发，独立部署，应用通过有限的API接口互相关联。API接口属于应用一部分，一般和表示层处于同一层次，两者共享业务逻辑层，API和表示层采用同样的web端技术，通讯协议一般使用HTTP，数据格式是JSON，应用集成方式比较简化。

分布式架构首先对系统按照业务进行垂直切分，对广度上复杂的业务实现物理解耦，应用内部还是水平切分，对深度上复杂的业务实现逻辑解耦。分布式架构也可以解决业务量大的问题，对于某些高并发/大流量系统，把系统切分为不同应用，针对资源需求特点（比如CPU/IO/存储密集型），通过加强硬件配置满足不同应用的需求，避免一刀切方式带来的资源浪费。

技术上，API采用标准的HTTP/JSON进行通讯，调用双方实现难度都不大，但是API一般是“裸奔”的，在系统层面，调用依赖关系不透明，调用可靠性缺乏保障，因此只适用应用之间依赖链路少，调用量不大的系统，即应用之间耦合确实够松的系统。

分布式架构应用的架构如下图所示：




优缺点：

分布式架构每个应用内部高内聚，独立开发、测试和部署，支持开发敏捷；同时应用之间松耦合，业务边界清晰，业务依赖明确，支持大项目并行开发，实现业务敏捷。

在分布式架构中，应用的表示层和API没有物理分离，需要同时满足自身业务需求和关联业务需求，相互影响，比如API接口会随着外部应用的需求经常变化，这会导致整个应用重新部署。

运行时，API以HTTP/REST方式通过网络对外提供接口，其通信可靠性和数据的封装性相对于进程内调用比较差，如果没有一些可靠的技术机制，如路由保障/失败重试/监控等， 裸奔的API方式将严重影响系统整体可用性。


3.SOA架构

广义上，SOA也是分布式应用架构一种，但内涵不同。

这里有两种类型的“应用”，应用1~N是前端应用，面向用户，服务1~N是service，只提供业务逻辑和数据。这些应用都是独立部署，前端应用不再通过API直接关联，而是通过后端服务共享业务逻辑。

此外相对于“裸奔”的API，SOA架构提供配套的服务治理，包括服务注册、服务路由、服务授权、服务降级、服务监控等等。这些功能通过专门的中间件支持，有中心化和去中心化两种方式。

SOA架构在分布式架构垂直切分的基础上，进一步把原来单体应用的业务逻辑层独立成service，做到物理上的彻底分离。

每个service专注于特定职责，实现系统核心业务逻辑，service之间通过互相调用，可以完成复杂业务逻辑，解决业务深度上的问题；同时service面向众多的应用，以共享的方式支持逻辑复用。所以，SOA架构既体现业务的分，又体现业务的合，更多地从业务整体上考虑系统拆分。

相比分布式应用架构，基于SOA的系统有大量的service应用，整个系统基于服务调用，所以对服务依赖的透明性和服务调用的可靠性提出很高要求，需要专门的SOA框架支持，还需要配套的监控体系和自动化的运维系统支持，技术复杂性高，SOA架构可以集中体现一个企业的IT技术能力。

SOA架构优缺点如下图所示：



优点：
    每个service都是浓缩的精华，聚焦某方面核心业务，同时以复用的方式供整个系统共享
    服务作为独立的应用，独立部署，接口清晰，很容易做自动化测试和部署
    服务是无状态的，很容易做水平扩展；通过容器虚拟化技术，实现故障隔离和资源高效利用，业务量大的时候，加机器即可
    基于SOA的系统可以根据服务运行情况，灵活调控服务资源，包括服务上下架、服务升降级等，使系统真正具备可运营的能力

缺点：
    系统依赖复杂，给开发/测试/部署带来一系列挑战。
    端到端的调用链路长，可靠性降低，依赖网络状况、服务框架及具体service的质量
    分布式数据一致性和分布式事务支持困难，一般通过最终一致性简化解决
    端到端的测试和排障复杂，SOA对运维提出更高要求


总结：

业务架构是生产活动的体现，应用架构是具体分工合作关系的体现。

单体应用类似原始氏族时代，氏族内部有简单分工，氏族之间没有联系；

分布式架构类似封建社会，每个家庭自给自足，家庭之间有少量交换关系；

SOA架构类似工业时代，企业提供各种成品服务，我为人人，人人为我，相互依赖。微内核的SOA架构类似后工业时代，有些企业聚焦提供水电煤等基础设施服务，其他企业在之上提供生活服务，依赖有层次。

业务架构是生产力，应用架构是生产关系，技术架构是生产工具。业务架构决定应用架构，应用架构需要适配业务架构，并随着业务架构不断进化，同时应用架构依托技术架构最终落地。