共计 1085 个字符，预计需要花费 3 分钟才能阅读完成。
微服务作为目前业界主流的设计架构，已经使用的很广泛了，但是实际并没有很明确的划分原则，这里主要总结一下常用的设计、划分原则。
微服务设计的四个原则
- AKF拆分原则
AKF扩展立方体，是由一个叫AKF公司总结的，按照三个维度，将一个单体系统进行无限扩展。
X轴：水平复制，就是将单体系统多运行几个实例，做个集群加负载均衡的模式；
Y轴：这个就是我们通常所说的微服务拆分，基于不同的业务拆分；
Z轴：基于类似的数据分区比如一个互联网打车应用，用户量激增，集群撑不住了，就可以按照用户的地区进行数据分区，比如北京，上海，杭州等建多个集群
- 前后端分离
前端和后端的代码在技术上做分离，后端不直接渲染前端页面
- 无状态服务
状态：如果一个数据需要被多个服务共享，才能完成一次交易，那么这个数据就被成为状态。依赖这个状态的服务就被成为有状态的服务，反之就是无状态服务。
无状态服务不是不允许存在状态，而是把有状态的服务转为无状态的计算类服务，然后把状态数据相应的迁移到有状态的数据服务中。
场景说明：例如我们在有状态的服务里建立的数据缓存，session缓存，到微服务架构中，就需要将数据迁移到分布式缓存中，让业务服务变成一个无状态的计算节点，这样的话，微服务在运行时，就可以动态增删节点，无需考虑服务间缓存数据如何同步
- Restful通信风格
1.资源以json为载体；2.统一接口（get获取资源，post新建资源，put完全替换资源，patch部分替换资源，delete删除资源）；3.URL的设计（API尽量部署在专用域名/主域名下，api中放入版本号，并且只能有名词，复数形式，不能有动词，可以考虑提供参数）；4.返回规定的状态码；5.统一的错误处理（例如以error为键名）
微服务设计目标
- 架构必须稳定
- 服务必须高内聚 — 每个服务应该实现的是强相关的功能
- 服务必须松耦合 — 每个服务都可以在不影响客户端的情况下更改实现
- 服务必须服务开闭原则 — 开：服务功能的扩展是开放的；闭：服务源代码的修改是闭合的
- 服务是可以单独测试的
- 每项服务的都小到可以由几个人的团队完成开发
- 负责每个服务的团队必须是自治的，尽量减少团队间的协作，来开发部署他们的服务
微服务划分方法
通过领域驱动设计，Domain Driven Design，简称DDD，设计与子域相对应的服务。DDD通过分析问题空间和业务逻辑，将应用程序定义为域。域由不同的子域组成，每个子域对于业务的不同部分。
子域可以分为以下几类：
- 核心类：业务的关键差异化因素和应用程序中最有价值的部分
- 支持类：与业务有关，但是与差异化无关
- 通用类：与业务无关，理想情况下可以使用现有的软件实现
