互联网架构设计漫谈 (4)-你知道微服务的“分与合”

互联网架构设计漫谈 (4)-你知道微服务的“分与合”

 

 

业务高速发展的今天，单应用已经无法支撑庞大/复杂的业务系统。所以需要根据业务进行拆分，方便业务做扩容，并且增加大系统的团队协作性，于是微服务就应运而生了。微服务讲究“分与合”，“分”就是按照业务边界把大的服务拆成小的服务让他们各司其职，“合”就是把这些微服务用合理的方式组合起来让他们协同工作。

 

要点：

微服务拆分原则

微服务协作方式

---

微服务拆分原则

按照业务划分边界，秉承高类聚松耦合的思想。

松耦合：能够独立开发修改以及部署单个服务而不需要修改系统的其他部分。服务不需要知道其他服务的实现细节，服务之前只需要定义调用的接口就好.

高内聚：尽量让服务内的功能单一，该功能的实现是业务系统中的较小单元。如果只是功能级别的变化，那么只用修改这个服务就可以了，不需要对其他的服务造成影响。一个微服务包括独自的业务领域，缓存，数据库，用单独的容器装载。

 

划分服务边界：微服务是为实际业务提供支撑的，所以需要我们的架构师对业务有足够的了解，把相关性比较高的业务放到一个服务中，定义其数据模型以及对外的接口。定义出需要隐藏的业务部分，以及需要共享的数据模型。例如：订单服务的范围包括订单的所有操作：下单，退单，确认订单等等；库存系统包括增减库存等操作。那么订单系统和库存系统需要通过接口进行访问，他们共享了“库存项”的数据模型。库存服务会被订单服务调用，那么订单服务就是消费者，库存服务就是服务提供者。

 

服务的消费者与服务的提供者

服务之间也存在互相调用的情况，例如：订单服务调用库存服务。有的服务既是服务的消费者又是服务的提供者，这个时候有可能出现循环调用。这样在服务版本升级的时候会出现混乱。

 

建议在这种情况下把服务分成两个不同的服务版本。针对具体情况升级版本。

 

微服务协作方式

通常微服务在调用的时候都存在服务的消费方和服务的提供方，消费方发起调用，提供方响应请求，并且返回结果。这个调用有同步和异步之分，为了提高响应的效果一般会采取异步调用的方式。那么这些服务在一起合作完成工作的时候，又会有编排和协同两种模式。通俗的说“编排”模式需要设计一个“中心处理”服务，其中记录了需要调用哪些服务。例如：中心服务“A”中会记录需要调用按照顺序调用服务“B”和“C”。那么请求只用向中心服务“A”发指令就可以了，中心服务自己去调用“B”和“C”，并且控制事务以及返回结果。如下图：

编排模式

这种模式的缺点很明显就是太过依赖这个中心服务了，所有的业务都会在“中心服务”汇总，稳定性和可扩展性都不好。

目前使用更多的是“协同”模式，接到用户请求以后系统自动发送“用户事件”，凡订阅了该“用户事件”的服务接受到该事件就自动完成自己的工作，做到各司其职。消除了“编排”模式带来的耦合，让服务之间的依赖更少。

协同模式

再来看看服务协同工作的全貌

 

客户端的请求最先进入“代理层”，通过“服务网关”获取调用服务的信息，特别是遇到同一服务名称多个实例的情况，这里会有特定的轮询机制访问具体的服务实例。同时“服务网关”也会从服务注册中心拉取服务注册的信息，这样一旦微服务注册到了“服务中心”就会被“服务网关”知晓。服务之间也可以直接通过REST或者RPC的方式调用。服务本身有缓存也可以使用分布式的缓存。每个服务由于配置的IP或者端口以及版本环境的差异，配置文件会有所不同，可以通过“配置管理”服务来完成。

总结：微服务拆分讲究“高内聚”，“松耦合”，按照业务边界来拆分。微服务之间可以通过服务注册中心，服务网关，配置管理，消息队列的方式协作。也就是微服务的“分与合”。