【架构设计】单体软件向微服务化演变

单体软件

假设单体软件的各模块如下，其中服务包含许多功能模块，如用户管理模块、商品模块、订单模块、仓库模块;

服务化

服务化是指对单体服务进行拆分，将一个服务软件拆分为多个相互关联的服务，他们之间相互协作，能正常完成原单体服务的所有业务。

服务化后，有如下优点：

• 服务化后的各服务能独立提供服务，某个服务损毁后，不影响其他业务的使用，软件整体的可用性提高了。
• 服务化后的软件代码依据各子服务管理，相对来说代码量少了，开发复杂性会成指数型减弱
• 服务化后的软件，各子服务独立维护，因此各服务更新维护也比较简单
• 服务化后的软件，由于各服务在不同节点独立运行，计算与网络资源成倍数形式增长。理论上来说，这使得软件的服务能力成倍提高

以下是对单体服务中的服务进行服务拆分的示意图。

部分服务分集群化

服务集群化

软件服务化后，使得软件的可用性、服务能力大大提高，然而其更多的价值在于使得软件的开发、维护更为简单。

在软件服务化后，随着软件使用的需求持续增长，依然会面临服务能力不足的问题。为了解决该问题，大家都会想到服务扩容，那么如何扩容呢？假定软件被拆分了10多个子服务，甚至更多。将所有服务都扩容一套嘛？

答案是否定的，扩容不是说说那么简单。众多子服务同时扩容，首先要面临成本问题。

一般情况下，服务扩容是根据各子服务的使用情况来指定灵活的扩容方案。对软件中服务压力大，硬件资源不足的节点进行灵活扩容。

如下是商品服务服务扩容的示意图，下图表示软件将商品服务扩增到了三个节点，这个三个节点通过负载均衡与软件中的其他服务相关协同。

商品服务以多个节点共同提供服务。这个服务群形成一个集群，即商品服务集群。

数据库集群化

随着服务的增长，对数据库的读写需求也会持续增长。其增长趋势与服务的使用趋势成正比。

当数据库服务能力遇到瓶颈时，也可以对其进行服务扩容。

因为数据层的服务扩容首先要保证扩容后所有数据服务之间的数据一致性问题 ，因此服务的集群化和数据层的集群化通常不一样。

• 服务集群化后，通常各个子服务之间的关系是均等的，它们可无差别的提供服务，任何一个服务损毁，都不影响整体软件的运行，除非所有集群中的所有服务都损毁。
• 数据层的服务集群化后，通常对服务进行主从节点划分。主节点主要负责数据写入，从节点主要负责数据读取。注意，除了主从这种模式外，还有去中心式服务模式。去中心式服务模式理论上每个服务都能进行数据读写。