03、如何设计微服务及设计原则

• AKF拆分原则
• 前后端分离
• 无状态服务
• Restful通信风格

一、AKF拆分原则

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

X 轴 ：指的是水平复制，很好理解，就是讲单体系统多运行几个实例，做个集群加负载均衡的模式。

Z 轴 ：是基于类似的数据分区，比如一个互联网打车应用突然或了，用户量激增，集群模式撑不住了，那就按照用户请求的地区进行数据分区，北京、上海、四川等多建几个集群。

Y 轴 ：就是我们所说的微服务的拆分模式，就是基于不同的业务拆分。

场景说明：比如打车应用，一个集群撑不住时，分了多个集群，后来用户激增还是不够用，经过分析发现是乘客和车主访问量很大，就将打车应用拆成了三个乘客服务、车主服务、支付服务。三个服务的业务特点各不相同，独立维护，各自都可以再次按需扩展。

也就是说Y轴代表了系统功能上的划分方向，X轴代表了功能或数据上的复制方向，Z轴代表了按照一定条件进行优先级划分：比如，同样是扩展系统能力，按照地域优先级来进行数据分区。

 

二、前后端分离

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

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

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

三、无状态服务

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

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

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

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

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

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

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

 

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

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

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

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

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