微服务设计原则
- AKF拆分原则
- Y轴（功能）
- X轴（水平扩展）
- Z轴（数据分区）
- 前后端分离
- 无状态服务
- RestFul通信风格（无状态通信原则）
AKF拆分原则
AKF扩展立方体是由一个叫AKF公司的技术专家总结出的应用扩展的三个维度。理论上安装这三个维度扩展，可以把一个单体系统进行无线扩展。
Y轴（功能）
按照功能拆分，基于不同的业务拆分。
X轴（水平扩展）
将微服务运行多个实例，做成集群加负载均衡的模式。
Z轴（数据分区）
基于类似的数据分区。例如互联网打车突然火了。用户量激增，集群模式撑不住了，那就可以按照用户请求的地区进行数据分区，建成北京、上海等多个集群。
前后端分离
前后端分离，不仅要做到技术代码的分离，还要做到物理分离的部署方式，不要使用之前的服务端模板技术，如JSP。
分离模式下，前后端交互界面更清晰，就剩下接口和模型，后端的接口简洁明了，更容易维护。
前端多渠道应用场景更容易实现，后端无需变更，采用统一的数据和模型，即可支撑PC前端、移动APP等访问。
无状态服务
状态：如果有一个数据被多个服务共享，则这个数据就是状态。
有状态服务：依赖于状态数据的服务。
无状态服务：不依赖状态数据的服务。
这里提到的无状态服务原则，并不是说在微服务中不允许存在状态，而是将有状态的业务服务改为无状态的计算服务，把“状态”数据迁移到对应的“有状态服务”中。
例如：本地内存中建立的数据缓存、Session缓存，到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点。
迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不再需要考虑缓存数据如何同步的问题。
RestFul通信风格（无状态通信原则）
无状态通信：每次通信都是独立的，不存在共用的数据（状态），不相互依赖某一数据。
无状态通信的最佳实践就是RESTful通信风格，RESTful具有如下优势：
天生适合无状态的HTTP协议，具有很强的扩展能力；
JSON报文序列化，轻量简单，人机均可读，学习成本低，对搜索引擎友好；
RESTful具有语言无关性，各大热门语言都有成熟的API框架。
