图解微服务应用的设计原则

前言

什么样的应用才算是一个微服务应用？怎么设计一个微服务架构的应用呢？今天我们就一起来看看微服务应用的那些设计原则。

设计原则1、AKF拆分原则

图注:AKF拆分原则

AKF扩展立方体，是一个AKF公司的技术专家抽象总结的应用扩展的三个维度，理论上按照这三个扩展模式，可以将一个单体系统进行无限扩展。

X轴：水平复制，即单个服务运行多个实例，做个集群加负载均衡的模式；

Z轴：类数据分区，即按用户的地域进行数据分区，北京、上海、深圳等多建几个集群；

Y轴：服务拆分模式。

2、前后端分离原则

图注:前后端分离

前后端分离，不仅要做到技术代码的分离，还要做到物理分离的部署方式，不要使用之前的服务端模板技术，如JSP。

分离模式下，前后端交互界面更清晰，就剩下接口和模型，后端的接口简洁明了，更容易维护。

前端多渠道应用场景更容易实现，后端无需变更，采用统一的数据和模型，即可支撑PC前端、移动APP等访问。

3、无状态服务

图注:无状态服务

状态：如果一个数据需要被多个服务共享，则这个数据就是状态。

有状态服务： 依赖于状态数据的服务称为有状态服务。

无状态服务： 不依赖状态数据的服务成为无状态服务。

这里提到的无状态服务原则，并不是说在微服务中不允许存在状态，而是将有状态的业务服务改为无状态的计算服务，把“状态”数据迁移到对应的“有状态服务”中。

eg：本地内存中建立的数据缓存、Session缓存，到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点。

迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不再需要考虑缓存数据如何同步的问题。

4、无状态通信原则（RESTful通信风格）

图注:无状态通信

无状态通信：每次通信都是独立的，不存在共用的数据（状态），不相互依赖某一数据。

无状态通信的最佳实践就是RESTful通信风格，RESTful具有如下优势：

天生适合无状态的HTTP协议，具有很强的扩展能力；

JSON报文序列化，轻量简单，人机均可读，学习成本低，对搜索引擎友好；

RESTful具有语言无关性，各大热门语言都有成熟的API框架。

如何进行服务划分

依托微服务四大设计原则，我们来看看如何设计微服务应用的服务粒度（服务划分）。

1、微服务的内外部世界

按照服务边界上下文（Bounded Context），我们可以将微服务应用的世界划分为外部世界和内部世界。

微服务的外部世界：

微服务外部的客户端、界面、系统、设备；

微服务之间的外部数据交换；

微服务之间的外部远程调用；

微服务的内部世界：

微服务内部需要实现的业务功能(场景)；

微服务内部所需的资源(类库、数据库、服务器、网络IP、操作系统等)

2、指导思想

就目前软件应用的现状来看，微服务的外部世界是十分脆弱和不可预期的，比如说网络：网络的中断、网络的安全、网络的延迟等都是脆弱和不可预期的。因此我们在设计微服务的服务划分时，需谨记微服务的“外部世界”远比“内部世界”重要这样一个指导思想。

遵循这一指导思想，我们应该从微服务“外部世界”来界定微服务的粒度，主要从以下几个方向去思考：

1、先从微服务的外部客户端分析和识别微服务的主要目的、需要处理和运算的业务场景(功能)是什么，从而得出微服务的Pre-Bounded Context.

2、根据Pre-Bounded Context，便可近一步分析，微服务之间的外部数据交换是否会增加开发的技术难度，是否会影响整体应用的架构可靠性，是否会存在分布式事务(数据一致性问题)，是否会产生其他负面影响。

3、在第二步的基础上，再近一步分析，是否因为微服务之间的外部远程调用过多，导致大量的网络延迟，从而影响整体应用架构的性能。

3、后话

假如有一天微服务的外部世界十分强壮了，那么我们便可从微服务内部世界来考量服务划分的粒度，比如考虑微服务持续部署的效率等问题。

图注:爱折腾的稻草