在我的《高并发系统设计目标之可扩展性》博文中提到，随着业务的发展，我们会沿着AKF的Y轴进行微服务化的改造。本文就介绍一下微服务化改造的基本原则
1、单个服务内部应该是高内聚低耦合的，也就是单一服务内部应该只做自己相关的事情，不是自己职责的功能交由其他服务完成，服务之间应该有明显的边界； 2、微服务化改造应该是边改造边支持业务的发展的，不能为了改造而停止业务的迭代。因为要是停止了业务的迭代，那么等你改造完，可能已经被竞品超越了，从而丧失了市场的机会，最终可能是竹篮打水一场空； 3、微服务提供的接口应该是可扩展的，变更接口后应该兼容以前的接口。因为其他服务可能还在用旧接口，你的服务可能有很多微服务会调用，而不同的微服务可能是跨团队维护的，不可能要求所有其他微服务同步更新。 4、微服务化改造应该是先粗后细，在刚开始改造时，服务的划分应该粗略一些，然后随着业务的发展与微服务的认知，在逐步细化。因为刚开始时团队对于微服务的认识可能没有那么深刻，而且也不知道最终业务要怎么发展，划分的过细，服务之间的调用关系就会更复杂，调用链更长，从而导致服务响应时间也会变长，开发运维成本也会增多，而且过细服务之间的耦合可能也比较强，最后可能还得合并与重新拆分。
微服务化改造应该是边改造边支持业务的发展，那么我们拆分服务就得有一个顺序，我们可以依据如下的顺序拆分服务： 1、优先拆分比较独立的与业务关系不大的边缘服务，如短信服务。这样可以给团队一个试错的机会，减少错误的发生； 2、优先拆分被依赖的服务，比如A依赖B，B又依赖C，那么应该优先拆分C，再拆分B，最后拆分A；如果先拆分A，那么A就依赖于一体式的系统了。 我们需要理清服务之间的调用关系，优先拆分边缘的独立性的服务，优先拆分被依赖的服务。拆分后的服务依赖关系应该是比较清晰，最好是一个树状结构，而不是一个复杂的网状结构。如果是网状结构，往往意味着服务之间的边界不够清晰，不满足高内聚低耦合。
1、微服务化后，接口之间的调用关系由原先的函数之间的调用关系，变成了通过网络实现的远程过程调用，那么服务的响应时间就会变长。而且服务的调用链往往较长，为此我们需要选用高效的RPC框架。但是远程过程调用需要知道被调用方的服务名，接口名以及IP地址与端口号，服务名与接口名往往是不会变的，但是服务部署的节点的IP地址与端口号往往是动态变化的，为此我们需要引入配置中心，以管理我们的薇服务。 2、微服务化后，请求的调用链条往往较长较复杂，如果调用链上的某个服务异常了（如crash、响应时间变长等），那么往往会导致上游服务的资源出现异常，最终导致上游服务也出现异常，然后继续传导，继而导致雪崩。为此我们需要引入限流、降级、熔断、超时控制、重试等服务治理功能，以保证系统的高可用。 3、微服务化后，请求的调用链条往往较长较复杂，那么如果调用链上的某个服务出现异常或者报错，如上所述调用链上的其他服务往往也会出现异常或者报错，那么我们怎么找到错误的源头呢？这时就需要调用链跟踪与服务监控功能了。
