不知道大家面临微服务改成头一件事是不是为如何拆分微服务而烦恼、纠结？到底这个系统该如何划分微服务？如何拆分才是比较好的？
今天，本作者就来结合这些年微服务改造的一些经验来谈谈到底该如何拆分微服务。
其实，一个系统究竟该如何拆分微服务，怎样拆才是最好的，其实并没有一个标准的答案。(对，就是没有一个统一而完美的答案，没有最好，只有更好!:),哈哈，开句玩笑的）。
一般而言，如果是一个全新系统，拆分微服务则不会那么纠结，因为，从零到一，一切可以根据自己的系统设计来拆，没有那么多条条框框的限制，这里本文将不再赘述。
接下来，本文重点分享的是如何在已有系统进行微服务改造，我相信，这是大家遇到的最多的一个问题。因为随着系统业务规模的扩展，好多老架构的系统都会面临着系统重构，而微服务架构目前是众多系统架构里的首选。在进行微服务架构改造之前，大家可以先从以下几个方面考虑以下：
1、已有系统的体量是多少？-->比如系统用户数多少，最大并发多少，日均IP和PV是多少？
如果已有系统是企业内部系统，系统本身使用的人就不是很多，比如一个100人左右的系统，最大并发20人左右，这样的系统就没必要跟时髦，为了微服务改造而改造。
那如果说，是一个全球性的互联网系统，遍布海内外的人都在使用，而且并发量还比较大，开发团队也遍布全球，更新上线也比较频繁，那这时可以考虑下微服务架构。
2、思考一下已有系统适合用微服务架构吗？用微服务架构的好处是什么？用了微服务架构后会解决什么问题？
已有系统的开发维护团队是一个技术栈的还是多个？系统的平均更新周期是多长？
如果说，已有系统的开发维护团队是一个，系统也是半年会一两年才更新一次，那就没必要用微服务架构，微服务架构的特点就是“短平快”。
当你的系统迭代次数较多，更新上线较频繁，而团队技术栈又比较多时，这样的团队微服务适合进行微服务架构开发。
3、系统的重构预算是否充足？
看似这跟技术好不相关，但搞技术的人也是需要吃饭的。要解决吃饭的问题就要考虑成本问题，一切不考虑成本进行重构的架构都是耍流氓！众所周知，微服务架构带来更敏捷的开发福利的同时，也比传统架构需要更多的部署和维护成本，需要培养多个技术栈的技术人员，由于是分布式部署，会用到额外的一些中间件，比如服务发现、服务网关、服务监控、负载均衡、消息队列等等集群。如果预算不够，投资回报率达不到要求，大型系统微服务改造之路十有八九会中途而废。现实中，就遇到很多失败的例子，改造前，好高骛远，什么都想搞，没有充分评估好风险，理想很美好，现实很残酷，结果半年下去，还是个半成品，被中途叫停。
4、如果上述三个问题都已具备微服务架构的条件，那么接下来我们还要分析下，已有系统中哪些适合微服务架构？其实，这是个伪命题，光看标题，还是不知道哪些适合哪些不适合。我们不妨这样来分析：
a.系统中哪些模块更新频率比较高-->系统前台、用户界面？
b.系统中哪些模块使用比较频繁，压力比较大？-->比如OA系统的审批模块、学习系统的考试、课件播放模块？
c.系统中哪些模块是共用的-->日志、邮件、权限控制。。。？
d.系统中哪些是RPC通信的-->用户消息通知，一些原有RPC通信
e.系统中哪些是实时性要求比较高的-->在线转账、短信通知？
f.哪些模块是前后台分离的？-->Portal前台？
。。。。。。
当然，上面abcde这几点都是考虑特殊情况的，其实，就一般而言，我们还是有一些基本的微服务拆分原则的：
1、AKF拆分原则
AKF扩展立方体
AKF扩展立方体(参考《The Art of Scalability》)，是一个叫AKF的公司的技术专家抽象总结的应用扩展的三个维度。理论上按照这三个扩展模式，可以将一个单体系统，进行无限扩展。
X 轴 ：指的是水平复制，很好理解，就是讲单体系统多运行几个实例，做个集群加负载均衡的模式。
Z 轴 ：是基于类似的数据分区，比如一个互联网打车应用突然或了，用户量激增，集群模式撑不住了，那就按照用户请求的地区进行数据分区，北京、上海、四川等多建几个集群。
Y 轴 ：就是我们所说的微服务的拆分模式，就是基于不同的业务拆分。
场景说明：比如打车应用，一个集群撑不住时，分了多个集群，后来用户激增还是不够用，经过分析发现是乘客和车主访问量很大，就将打车应用拆成了三个乘客服务、车主服务、支付服务。三个服务的业务特点各不相同，独立维护，各自都可以再次按需扩展。
2、前后台分离原则
前后端分离原则，简单来讲就是前端和后端的代码分离也就是技术上做分离，我们推荐的模式是最好直接采用物理分离的方式部署，进一步促使进行更彻底的分离。不要继续以前的服务端模板技术，比如JSP ，把Java JS HTML CSS 都堆到一个页面里，稍复杂的页面就无法维护。这种分离模式的方式有几个好处：
前后端技术分离，可以由各自的专家来对各自的领域进行优化，这样前端的用户体验优化效果会更好。
分离模式下，前后端交互界面更加清晰，就剩下了接口和模型，后端的接口简洁明了，更容易维护。
前端多渠道集成场景更容易实现，后端服务无需变更，采用统一的数据和模型，可以支撑前端的web UI\\ 移动App等访问。
一个前后端分离的微服务架构：
前端用纯js+html+css或前端框架（Reat\\Angular\\Vue）,
后端用webapi(c#\\java\\node.js\\php...)
3、无状态服务原则
对于无状态服务，首先说一下什么是状态：如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数据被称为状态。进而依赖这个“状态”数据的服务被称为有状态服务，反之称为无状态服务。
那么这个无状态服务原则并不是说在微服务架构里就不允许存在状态，表达的真实意思是要把有状态的业务服务改变为无状态的计算类服务，那么状态数据也就相应的迁移到对应的“有状态数据服务”中。
场景说明：例如我们以前在本地内存中建立的数据缓存、Session缓存，到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点。迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不再需要考虑缓存数据如何同步的问题。
閱讀更多 墨漂碼農 的文章
