很多传统企业看着互联网公司都进行着微服务化，因此也想享受微服务化带来的好处便对自己的系统进行改造，但微服务化 多“微”才是最优？有哪些拆分的原则？

架构原则

• 使用成熟的技术，不需要最先进最好的技术，要是自己人能够掌控的，不然出现莫名的问题，一两天都可能解决不了，你就等着被拿来“祭天”吧。
• 至少有一个冗余的实例，可水平扩展，确保一个实用多个负载，挂掉一个仍然能够正常运行，这里就要保证服务应用的无状态性。
• 确保数据中心能在地理上隔离，实现异地多活容灾，实现三城两地式物理布署，即使一个城市停电仍可提供数据的正常访问。
• 有一套发布回滚机制，确保发布异常时能回滚到上一个版本，同时可追踪到异常。
• 在架构设计之初就构建监控平台，无监控无疑相当于系统在裸奔，后面扩容无数据支撑、BUG查找，异常追踪都无从淡起。
• 不断小试错，而不是像传统项目开发周期达一年，在时间就是生命的时代，产品上线黄花菜都凉了。
• 任务自动化，机器能够做就让程序自动跑，减少人力运维。
• 实现故障隔离，自动保护机制，防止一个服务拖垮整个系统平台，进行健壮性分析。
• ……

　　所有的设计都是为了高可用，易扩展、高并发下出现异常更容易恢复，降低异常对业务的影响，这就是微服务架构设计的理念，但不完全，有些还是依靠架构师的经验结合自己公司的业务特点来思考，并不是适合所有的公司，传统公司进行微服务化的困难很大，但做得好收益也非常高。

做好业务的拆、合

　　微服务讲究的是小 ，一个程序只做好一件事就够了，因此需要对原有臃肿的系统拆分，对零散的功能进行合。

 一个业务场景一个服务

　　如用户服务、授权服务、菜单服务、订单服务…… 这样的粒度好处是更新用户服务其它的服务可以不用更新。

一个数据库对应一个服务

　　数据库操作层封装成一个服务，所有对这个数据库的请求都要经过这个服务，而不用知道这个数据库的密码，而且可以进行流量权限等进行控制。

一个接口一个服务

　　这种架构很极端，会造成微服务数量成几何数增长，维护难度极大。

　　适当的粒度优势是服务能够独离部署，扩展方便，耦合度较小。

　　应用层我们可以结合上面的方法从下往上分析，对所有服务抽像化后抽出基础功能封成服务，这样公共服务就行成了，而且可以互相引用。

　　这样就形成了基础服务，是一些基础组件，与具体的业务无关。比如：短信服务、邮件服务。这里的服务最容易摘出来做微服务，也是我们第一优先级分离出来的服务。

　　还有些是业务服务，是一些垂直的业务系统，只处理单一的业务类型如：风控系统、积分系统、合同系统。这类服务职责比较单一，根据业务情况来选择是否迁移，比如：如果突然有需求对积分系统进行大优化，我们就趁机将积分系统进行改造，是我们的第二优先级分离出来的服务。
前端服务，一般为服务的接入或者输出服务，比如网站的前端服务、app 的服务接口这类，这是我们第三优先级分离出来的服务。
组合服务，组合服务就是涉及到了具体的业务，比如网购过程，需要调用很多垂直的业务服务，这类的服务我们一般放到最后再进行微服务化架构来改造，因为这类服务最为复杂，除非涉及到大的业务逻辑变更，我们是不会轻易进行迁移。

独立数据库

　　数据层都是独立的数据库，即一个数据库对应一个服务，这里需要对数据库层进行纵向切分，即原来一个表现在对应多个表分片保存。

给数据库带来的挑战

　　每个微服务都有自己独立的数据库，那么后台管理的联合查询怎么处理?

有如下三种处理方案：

• 严格按照微服务的划分来做，微服务相互独立，各微服务数据库也独立，后台需要展示数据时，调用各微服务的接口来获取对应的数据，再进行数据处理后展示出来，这是标准的用法，也是最麻烦的用法。
•  将业务相关的表放到一个库中，将业务无关的表严格按照微服务模式来拆分，这样既可以使用微服务，也避免了数据库各种切换导致后台统计难以实现，是一个折中的方案。
• 数据库严格按照微服务的要求来切分，以满足业务高并发，实时或者准实时将各微服务数据库数据同步到 NoSQL 数据库中，在同步的过程中进行数据清洗，用来满足后台业务系统的使用，推荐使用 Mongodb、Hbase 等。

拆分过后落地架构

• 在确定使用Spring Boot / Cloud 这套技术栈进行微服务改造之前，请先梳理平台的服务，对不同的服务进行分类，以确认演化的节奏。
• 先让团队熟悉 Spring Boot 技术，并且优先在基础服务上进行技术改造，推动改动后的项目投产上线。
• 当团队熟悉 Spring Boot 之后，再推进使用 Spring Cloud 对原有的项目进行改造。
• 在进行微服务改造过程中，优先应用于新业务系统，前期可以只是少量的项目进行了微服务化改造，随着大家对技术的熟悉度增加，可以加快加大微服务改造的范围。
• 传统项目和微服务项目共存是一个很常见的情况，除非公司业务有大的变化，前期不建议直接迁移核心项目，先搭建一个微服务架构，然后先接入新业务，后面再将老项目逐个改造，这里有个问题就是统一配置，统一规则，如日志，接口，文档，代码风格，公共类库 版本等等提前规范。

　　以上只是个拆分建议，传统项目到微服务转化首先是思想上的转变就是很困难的，然后有些方法也不能套大公司的，只能是趋向大原则，根据自己的业务量，人力 时间等来改造。