目录
总的思路
拆分中需要注意的细节
1.事务一致性问题
2.数据权限和功能权限的处理。
3.拆分的粒度
4.子模块是否需要拆开放入不同的库
5.分库分表的设计
一、AKF拆分原则
1，Y轴（功能）关注应用中功能划分，基于不同的业务拆分
2，X轴（水平扩展）关注水平扩展，也就是“加速器解决问题”
3，Z轴（数据分区）关注服务与数据的优先级划分，如按地域划分
二、前后端分离原则
三、无状态服务
四、RestFul通讯风格
总的思路
大白话篇：微服务的拆分，可以按照业务来拆分 和 功能来拆分!
业务来拆分：将同一类业务放在一起，形成一个独立的进程服务。比如订单服务，用户服务，商品服务，支付服务，物流服务等等。
功能拆分：把相同或者相似的功能放在一起，比如接入支付：阿里支付，微信支付，银联支付，快钱支付等等，都属于支付的处理，可以按照功能放入到一起去。
拆分中需要注意的细节
1.事务一致性问题
如果系统对事务一致性要求比较高，则拆分时候一定要保证事务的一致性。 同一个库中可以采用事务，不同库中分布式事务，缓存，消息的机制，完成事务一致性的处理。
2.数据权限和功能权限的处理。
某些系统对数据权限和功能权限有着苛刻的要求，如何保证数据权限和功能的处理，则尤为重要。
3.拆分的粒度
不管是按照业务拆分，还是按照功能拆分，粒度的把控都尤为重要，不同的粒度，拆分出的结果和实现周期可能不同。
4.子模块是否需要拆开放入不同的库
一个进程（服务）对应一个库，这个在拆分的时候也需要考量。
5.分库分表的设计
一旦微服务拆完之后，分库分表的考量就必须提上日程，是否需要，分库分表的规则等等。
总结：没有一个恒定的标准说明微服务应该怎样拆分，应该使用哪些组件，那种策略，主要还是在使用者本身的功底。最终的目的是相同的，但是路径可以有很多种。印证了那句：条条大路通罗马！
以下是一些国外的拆分规则：
一、AKF拆分原则
业界对于可扩展系统架构设计有一个朴素的理念：通过加机器就可以解决容量和可用性问题。
这一理念在云计算概念疯狂流行的今天，得到了广泛的认可，对于一个规模迅速增长的系统而言，容量和性能问题当然是首当其冲的。但随着时间的向前，系统规模的增长，除了面对性能与容量的问题外，还要面对功能与模块数量上的增长带来的系统复杂性问题以及业务的变化带来的提供差异化服务的问题。
然而许多系统在架构设计时为充分考虑这些问题，导致系统重构成为常态，而影响业务交付能力，还浪费人力财力。对此《可扩展艺术》一书提出了一个系统可扩展模型–AKF可扩展立方（Scalability Cube）。
1，Y轴（功能）关注应用中功能划分，基于不同的业务拆分
Y轴扩展会将庞大的整体应用拆分为多个服务，每个服务实现一组相关的功能，如订单管理、客户管理等。在工程上常见的方案是服务化架构（SOA），比如对于一个电子商务平台，我们可以拆分成不同的服务，组成类似下面的架构：
、
但通过上图可以发现，当服务数量增多时，服务调用关系变得复杂，为系统添加一个新功能，要调用的服务数变得不可控，由此引发了服务管理上的混乱，所以一般情况下，需要采用服务注册的机制形成服务网关来进行服务治理
2，X轴（水平扩展）关注水平扩展，也就是“加速器解决问题”
X轴扩展与我们前面朴素理念是一致的，通过绝对平等的复制服务与数据，以解决容量与可用性的问题，其实就是将微服务运行多个实例，做集群加负载均衡的模式。
为了提升单个服务的可用性与容量，对每一个服务进行X轴扩展划分。
3，Z轴（数据分区）关注服务与数据的优先级划分，如按地域划分
Z轴扩展通常是指基于请求者或用户独特的需求，进行系统划分，并使得划分出来的子系统相互隔离但又是完整的。以生产汽车的工厂来举例：福特公司为了发展在中国的业务，或者利用中国的廉价劳动力，在中国建立一个完整的子工厂，与美国工厂一样，负责完整的汽车生产。这就是一种Z 轴扩展。
工程领域常见的Z轴扩展有以下两种方案
1，单元化架构
在分布式服务设计领域，一个单元Cell就是满足某个分区所有业务操作的自包含闭环。如上面我们说到的Y轴扩展的SOA架构。客户端对服务端节点的选择一般是随机的，但是，如果在此上加Z轴扩展，那服务节点的选择将不再是随机的，而是每个单元自成一体。
2，数据分区
为了性能数据安全上的考虑，我们将一个完整的数据集按一定维度划分出不同的子集。一个分区（Shard），就是整体数据集的一个子集。比如用尾号来划分用户，那同样尾号的那部分用户就可以认为是同一个分区，数据分区一般包括以下几种数据划分形式：
数据类型：如业务类型
数据范围：如时间段、用户ID
数据热度：如用户活跃度、商品热度
按读写分：如商品描述、商品库存
二、前后端分离原则
何为前后端分离？前后端本来不就是分离的吗？这要从jsp开始讲起。分工精细化从来都是蛋糕做大的原则，多个领域工程师最好在不需要接触其他领域知识的情况下合作，才能使效率越来越高，维护也会变得简单。jsp的模板技术融合了html和java代码，使得传统MVC开发中的前后端如胶似漆，前端做好页面，后端转成模板，发现问题再找前端，前端又看不懂java代码，前后端分离的目的就是打破这尴尬的局面，我们需要的是一个全能的团队，而不是一个个全能的人。
前后端分离原则，简单的将就是前端和后端的代码分离，我们推荐的模式是最好采用物理分离的方式部署，进一步促使更彻底的分离。如果继续使用服务端模板技术，如jsp，把java、js、css、html都堆到一个页面里，稍微复杂一点的页面就无法维护了。
这种前后端分离有几个好处：
1，前后端技术分离，可以由各自的专家来对各自的领域进行优化，这样前端的用户体验会更好。
2，分离模式下，前后端交互界面更清晰，就剩下接口模型，后端接口简介明了，更易于维护。
3，前端多渠道继承场景更容易实现，后端服务无需变更，采用统一的数据和模型，可以支持多个前端，例如：微信h5前端、PC前端、安卓前端、IOS前端。
三、无状态服务
对于无状态服务，首先说一下什么是状态：如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数据被称为状态。进而依赖这个状态的服务被称为有状态的服务，反之成为无状态服务。
这个无状态服务原则并不是说在微服务架构里不允许存在状态，表达的真实意思就是要把有状态的业务服务改变为无状态的计算类服务，那么状态数据也就相应的迁移到对应的“有状态数据服务”中。
场景说明：例如我们从前在本地内存中建立的数据缓存、Session缓存，到现在微服务架构中就应该把数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点。迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不再需要考虑缓存数据如何同步的问题。
四、RestFul通讯风格
这里介绍一个“无状态通讯原则”-Restful通讯风格，它有许多优点：
1，无状态协议HTTP，具备先天优势，扩展能力强，例如安全加密有成熟的https。
2，JSON报文序列化，轻量简单，人与机均可读，学习成本低，搜索引擎友好。
3，语言无关，各大热门语言都提供成熟的Restful API框架，相对一些其他RPC框架生态更加完善。
更多细节，还是在具体业务具体场景去分析。
同时：拆分还涉及到工作量的安排，人员的安排，项目紧急程度，外部系统调用，调用外部系统等等的因素，
没有一个完整的，标准的规则让你去按照规则来行事。
现实还是：还是具体问题，具体对待吧… ….
