微服务架构作为目前使用的主流架构，已经被广泛使用，但是对于服务的划分却没有固定的原则，在工作中也经常会出现服务划分过度或者不充分的情况。所以在这里想探讨一下服务边界和服务划分的方法。

   微服务设计四个原则：

• AKF拆分原则

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

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

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

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

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

• 前后端分离

前后端分离原则，简单来讲就是前端和后端的代码分离也就是技术上做分离，我们推荐的模式是最好直接采用物理分离的方式部署，进一步促使进行更彻底的分离

• 无状态服务

对于无状态服务，首先说一下什么是状态：如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数据被称为状态。进而依赖这个“状态”数据的服务被称为有状态服务，反之称为无状态服务。

那么这个无状态服务原则并不是说在微服务架构里就不允许存在状态，表达的真实意思是要把有状态的业务服务改变为无状态的计算类服务，那么状态数据也就相应的迁移到对应的“有状态数据服务”中。

场景说明：例如我们以前在本地内存中建立的数据缓存、Session缓存，到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点。迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不再需要考虑缓存数据如何同步的问题。

• Restful通信风格

作为一个原则来讲本来应该是个“无状态通信原则”，在这里我们直接推荐一个实践优选的Restful 通信风格 

微服务设计目标

• 架构必须稳定；
• 服务必须高内聚 - 服务应该实现一小组强相关的功能；
• 服务必须符合开闭原则 - 将一同变更的内容打包在一起，以确保每个更改仅影响一个服务；
• 服务必须松耦合 - 每个服务都可以在不影响客户端的情况下更改实现；
• 服务应该是可测试的；
• 每项服务都小到足以由“两个披萨”团队开发，即一个6-10人的团队；
• 负责一个或多个服务的每个团队必须是自治的 - 团队能够在与其他团队尽量少的协作下，来开发和部署他们的服务。

服务划分方法

通过领域驱动设计（DDD），设计与 子域 相对应的服务。DDD通过分析问题空间和业务逻辑，将应用程序定义为域。域由多个子域组成。每个子域对应于业务的不同部分。

子域可分为以下几类：

• 核心类 - 业务的关键差异化因素和应用程序中最有价值的部分；
• 支持类 - 与业务有关，但与差异化无关；这些可以在内部实施或外包；
• 通用类 - 与业务无关，理想情况下可以使用现成的软件实现。

例如一个会员账号管理系统包含以下几个子域：

    账号管理域：包含账号的模型和提供的基本接口能力

    登录模块域： 涉及登录和免登流程

    注册账号域： 账号注册和账号创建能力

    个人中心域： 涉及个人中心管理