认识达内从这里开始

微服务的架构开发应用是目前大多数软件开发程序员都在学习的一项互联网技术，而本文我们就通过案例分析来简单了解一下，微服务迁移与拆分策略都有哪些。

一、微服务迁移准备

1、需对业务充分了解，这是服务拆分，通信设计，资源整合的必要前提。

2、适应微服务架构设计原则：小版本，高速迭代。

3、快速的环境提供能力：依赖于云计算、容器技术，快速交付环境。

4、服务合理拆分：需符合团队结构或能逆向影响，能对组织架构进行微调并划分职责。(康威定律和逆康威定律)

5、基本的监控能力：包括基础的技术监控和业务监控。

6、快速的应用部署能力：需要部署管道提供快速的部署能力。

7、DevOps自动化运维能力：需要具有良好的持续集成和持续交付能力，还需要对问题、故障的快速响应能力，开发、测试和运维能协同工作。

二、微服务颗粒的拆分策略

微服务拆分没有一个绝对的标准答案，服务拆分的粒度需要根据业务场景来规划，而随着业务的发展，原先的架构方案也需要做调整。

虽然没有固定的套路，但是我们在业务实践过程中总结的一些经验，以做参考。

1、基于业务逻辑拆分

基于业务逻辑拆分相对好理解一点，的单一职责原则，我们将功能相近的业务整合到一个服务颗粒上。比如一个办公领域系统，考勤、工作流、音视频会议是是三个截然不同的业务领域，这可能就是我们拆分的一个入手点。

2、领域模型拆分

领域驱动设计DDD(Domain-DrivenDesign领域驱动设计)是一个很简单的概念，表示我们对系统的划分是基于领域的，也即是基于业务方向去思考的。

电商的业务体系庞大，涉及各方面的细节。但是我们大概能够根据业务的职能做一个拆分，比如阿里的电商中台业务，包含用户账号子系统、商品子系统、订单子系统、客户子系统、物流子系统等。

因为职能不同，这些领域之间包含清晰的界限，所以我们可以按照这个方向将服务于不同领域(商品域和订单域)的子系统拆成独立的服务颗粒。

3、用户群体拆分

根据用户群体做拆分，我们先要了解自己的系统业务里的用户角色领域是否没有功能耦合，有清晰的领域界限。

比如教育信息化系统，教师的业务场景和学生的业务场景，基本比较独立，而且拆分后流量上有明显的削弱，这时候结合具体的业务分析，看是否有价值。

4、基于可扩展拆分

这个需要区分系统中变与不变的部分，不变的部分一般是成熟的、通用的服务功能，变的部分一般是改动比较多、满足业务迭代扩展性需要的功能，我们可以将不变的部分拆分出来，作为共用的服务，将变的部分独立出来满足个性化扩展需要。

同时根据二八原则，系统中经常变动的部分大约只占20%，而剩下的80%基本不变或极少变化，这样的拆分也解决了发布频率过多而影响成熟服务稳定性的问题。

5、核心模块拆分

我们团队在做MySQL数据库和Redis集群拆分的时候，总会把一些重要的模块独立放在一个集群上，不与其他模块混用，而这个独立的集群，服务机性能要是好的。这样做的目的是，当重要度较低的模块发生故障时，不会影响重要度高的模块。

同要的道理，我们会将账号信息、登录信息、服务中心等重要度高的要害模块单独拆分在一个服务颗粒上(因为这类模块不可用之后，整个系统基本完全瘫痪)，再做成服务集群，来保障它的高可用。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。