三言两语说软件架构演变

目录

1 单体无层，一体化方式

2 单体分层，根据职责划分

3 分层部件框架化

4 面向服务架构，即SOA

5 微服务

6 其他架构模式

7 总结

---

1 单体无层，一体化方式

主要用于解决科学计算或者以某种单一功能的应用软件开发为主。组织方式上，多以个人或小团队为主。

2 单体分层，根据职责划分

此时期不再以科学计算为主，而是面向生活中的各种业务领域，功能众多且复杂，逐渐向平台化发展。通常分为展示层，业务逻辑层以及数据层三个大的方面，抽象和去耦合思想明显。组织上，也逐渐扩大为团队化作战。根据康威定律，组织结构反映系统架构。实际中，团队也多分为展示团队、业务逻辑团队和数据团队。

总的来讲，单体应用，瓶颈不容易定位，定位后不容易修改，水平扩展不容易实施。

3 分层部件框架化

这一时期，抽象程度继续提升。随着时间的推移，软件开发中，积累和沉淀了很多共性的东西，这些东西因为抽象程度好，逐步被框架化。这是层次化进一步的分裂。

4 面向服务架构，即SOA

主要针对历史遗留系统，两种方案，WebService+XML+服务注册发现和ESB企业服务总线方式。SOA架构主要解决传统应用之间的整合问题，从最底层的通信、传输整合到上层的数据、业务、应用整合，为打通信息孤岛提供一整套解决方案。

5 微服务

两个点，一个是微，一个是服务。把服务执行拆分，粒度更小，功能更单一，职责更专注（集中精力解决单类问题），整体更轻巧。

单进程的单体应用，整体上编译、测试、部署、维护都偏重，而微服务多采用容器部署，支持DEVOPS，比较方便纳入自动化运维体系框架内，且可快速多实例部署，天然支持集群，又因为分而治之，降低了整体复杂度，修改变化负担小，容易实现无缝切换、替换。

微服务架构，服务粒度不仅小，而且独立，甚至一个服务可以包括UI+业务逻辑+数据，倾向于小团队支撑，把一件事做细做精。而服务化架构，粒度大一些，更重一些，强调通过XML配置服务进行服务间的交互，比如通过SOAP，倾向于将原有应用进行服务化改造，以此借用SOA架构打通应用之间的壁垒。低级别的互通是通信传输层面的互通，而高级别的互通是业务层面的融合。

所以，微服务与SOA的差异，从典型技术层面来看，微服务采用容器技术，单体应用拆分为服务应用，突出拆；而面向服务SOA，更倾向于整合现有的多个大型应用，突出合。

进一步的，微服务应用解决问题多在于单体应用庞大臃肿，调试不便，编译不便，测试不便，验证不便，部署不便，维护不便。SOA 应用之间无必然联系，各个应用解决的是一种大业务类型。比如电商应用，人员管理应用，企业应用等。这里的应用就是微服务要进行拆的单体应用，比如对于电商应用，拆分为订单服务、库存服务、发货服务、购物车服务、商品评价服务等等。SOA应用之间主要解决的问题是信息不通，孤岛化，信息冗余等问题。采用的解决方案多是利用数据总线方式，定义标准的数据交换格式，大家连接到总线上，采用标准数据格式相互通信，相互关联。这样将企业遗留应用整合起来，充分发挥各应用的剩余价值，减少企业IT领域的重复投资，保护已有投资，使得投入产出最大化。

微服务的微是服务的特点，服务的独立、职责单一不代表服务的孤立。相反，因为服务职责单一后，为提供完整功能，反而催生了巨大的服务间交互需求。对于微服务之间的通信，有多种方式，包括：（1）底层Socket原始方案，操作系统原生支持，跨平台，但是灵活性、适应性、扩展性差，存在调试时间长，难以复用，风险大等问题，比较适用于简单的交互。（2）RPC方式，有基础框架可以复用，高度抽象化，灵活可扩展。数据内容支持二进制方式，也有可读文本方式，比如XML、JSON都可以。但这种方式跨语言跨平台较难，服务交互双方都需要同步采用相同框架，这是局限所在。（3）进一步的有RESTfull方式，基于HTTP，不受上述平台、语言的限制，但效率稍低。另外，存在反复建立断开连接问题。上述方式均为同步或基本按同步方式通信，在信息多、数据量大、高并发场景下，不适合，容易成为系统的瓶颈。此时，需要采用异步通信方案来破这个结。（4）典型的异步通信方案是采用消息队列方式，可以有效的起到削峰填谷的作用。但是系统的设计实现相对复杂，需要仔细处理。好在消息队列的实现有许多成熟的框架可用，一般系统中，精力放在异步消息设计上即可。

参考：孔乙己第一问之服务通信知多少？_龙赤子的博客-CSDN博客

6 其他架构模式

无服务：

云原生：

低代码：

无代码：

7 总结

这么多模式，该用哪一种好呢？其实，需要把握的关键一点是，并不存在所谓的十全十美的架构。选择哪一种模式，重点在于要处理的业务场景是什么，需要解决的主要矛盾是什么。这样，结合各种模式的特点和适用场景，就比较好选择了。