软件架构演进浅析

进入IT行业6年，见证了整个系统架构的变迁，经历了一轮又一轮架构浪潮。从最早的单体架构的一整个系统的杂乱无章，发展到多模块的单体架构，再到SOA架构的分布式解构系统，进而又更进一步进化到当今流行的微服务架构。每一种架构形态都不是万能的，都有其优劣所在，以及其所适应的场景和团队构成。

1. 单体架构

单体架构不是一无是处的，任何架构都有其优势和劣势。单体快速开发和验证想法，证明产品思路是否可行，投入资源和成本，包括人力和物力相对比较节约。但是随着时间的推移，业务复杂度的增加，单体架构会存在一些缺陷。

单体架构的缺陷：

（1）随着业务的复杂度增加，单体的灵活度会逐渐下降。

（2）IDE过载：随着代码量增加，代码整体编译效率下降。

（3）规模化：无法满足团队规模化高效开发。

（4）系统开发、测试、部署的冲突和效率低下等问题

（5）只能关注一套技术栈

（6）应用扩展性比较差

（7）海量用户高并发访问数量有限

架构设计的三大原则：简单，合适，演化。对于项目起步阶段，单体是最高效也是最节省成本的方式。因为初期阶段，由于人力，成本，业务熟悉程度，微服务技术积累等因素，如何过度设计可能工期和复杂度会急剧上升，造成交付困难，问题百出，从而错过了时间窗口。最合适，简单的方式还是单体优先，这是创业公司的特点决定的。当然设计面向微服务的单体架构也是一种聪明的方法，这遵守了系统演化的法则。

无论采取何种维度的架构分层，分层的最核心目的是保证各层之间的差异足够清晰，边界足够明显，为将来可能产生的变化提供最容易、最小化的修改。

如果前期在业务不十分清晰，求的是验证想法，证明产品思路是否可行性，并且业务量不大，仅限于省级范围，建议只要对当前架构稍加改良升级就可以了，这样改动量相对较小。

总之一句话总结：新系统不适合采用微服务，来做细粒度的拆分，因为业务不清，主次不明，反而可能造成系统混乱，更适合模块化的单体应用来做第一步开发。

 

2. SOA架构

SOA 全称是: Service Oriented Architecture，中文释义为 “面向服务的架构”它是一种设计理念，其中包含多个服务， 服务之间通过相互依赖最终提供一系列完整的功能。各个服务通常以独立的形式部署运行，服务之间 通过网络进行调用。

SOA的核心理念为：松耦合带来的服务重用，通过服务编排助力业务的快速响应和创新。

系统集成：站在系统的角度，解决企业系统间的通信问题，把原先散乱、无规划的系统间的网状结构，梳理成 规整、可治理的系统间星形结构，先散乱、无规划的系统间的网状结构，梳理成 规整、可治理的系统间星形结构，这一步往往需要引入一些产品，比如 ESB、以及技术规范、服务管理规范； 这一步解决的核心问题是有序。

系统的服务化：站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生，目的：把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用；这一步解决的核心问题是复用。

业务的服务化：站在企业的角度，把企业职能抽象成 可复用、可组装的服务；把原先职能化的企业架构转变为服务化的企业架构，进一步提升企业的对外服务能力；“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。第三步，则是以业务驱动把一个业务单元封装成一项服务。这一步解决的核心问题是高效。

SOA架构有如下优点：将重复的功能抽取为服务，提高开发效率，提高系统的可重用性、可维护性。可以针对不同服务的特点制定集群及优化方案。采用ESB减少系统中的接口耦合。

但也存在明显的缺点：系统与服务的界限模糊，不利于开发及维护。虽然使用了ESB，但是服务的接口协议不固定，种类繁多，不利于系统维护。抽取的服务的粒度过大，系统与服务之间耦合性高。

 

3. 微服务架构

SOA的出现其实是为了解决历史问题：企业在信息化的过程中会有各种各样互相隔离的系统，需要有一种机制将他们整合起来，所以才会有上边所述的ESB的出现。同样的，也造成了SOA初期的服务是很大的概念，通常指定的一个可以独立运作的系统（这样看，好像服务间天然的松耦合）。这种做法相当于是「把子系统服务化」。

而微服务没有历史包袱，轻装上阵，服务的尺寸通常不会太大，关于服务的尺寸，在实际情况中往往是一个服务应该能够代表「实际业务场景中的一块不可分割或不易分割的业务实体」。

微服务架构倡导将软件应用设计成多个可独立开发、可配置、可运行和可维护的子服务，子服务之间通过良好的接口定义通信机制，通常使用 RESTful 风格的 API 形式来通信 ，因为RESTful 风格的 API 通常是在 HTTP 或者 HTTPS 通道上传输 JSON 格式的数据来实现的， HTTP协议有跨语言、跨异构系统的优点， 当然，也可以通过底层的进制协议、消息队列协议等进行交互。这些服务不需要中心化的统一管理，每个服务的功能可自治，并且可以由不同的语言、系统和平台实现。

微服务架构有如下优点：

（1）易于开发和维护：一个微服务只会关注一个特定的业务功能，所以业务清晰、代码量较少。开发和维护单个微服务相对简单。

（2）单个微服务启动较快

（3）局部修改容易部署：单体应用只要有修改，就得重新部署整个应用。微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可。

（4）技术栈不受限制：在微服务架构中，可以结合项目业务及团队的特点，合理的选择技术栈。

（5）按需伸缩：可根据需求，实现细粒度的扩展。

但是微服务架构也是存在明显的缺点：

（1）运维要求高：更多的服务意味着要投入更多的运维。

（2）分布式固有的复杂性：使用微服务构建的是分布式系统。对于一个分布式系统，系统容错、网络延迟、分布式事务等都会带来巨大的问题。

（3）接口调整成本高：微服务之间通过接口进行通信。如果修改某一个微服务的API，可能所有用到这个接口的微服务都需要进行调整。

总之，微服务架构场景设计方面，要尽可能避免产生分布式事务，尽量按照BASE原则，采用最终一致性。小规模新项目，不建议采用微服务架构，拆得不好，反而会产生混乱。

 

4. 架构展望中台化

合久必分，分久必合，由于微服务化，导致服务碎片化，调用链路复杂，服务之间依赖关系杂乱，从而很多大型企业将高内聚低耦合的平台能力打包成中台化的系统，供前台系统调用。中台化，最近在架构圈很火热，但是也要看到中台化，是在基础能力都拆解到位，基础后台能力均具备的前提下，面向于敏捷化管理的一种后端平台演变路径。

中台的出现，是为了满足前台不断变化的需求，以及后台需要稳定和安全无法满足需求的快速变化，从而抽取出来中台层来匹配前台业务的变化，提取出可服用的企业级能力包，来满足前台的不断变化的业务需求。

中台的落地不仅仅是软件系统组织形态的变化，也需要企业组织形态变化相呼应，比如说原来每个业务系统都有自己的订单中心，现在企业抽出来统一的订单中心中台系统，来支持各个业务的订单业务，这也就意味着原来各个系统负责订单子系统的人员的调整与划转。没有企业人员组织架构的调整来配合，中台化是没有办法很好落地的。