https://archerzdip.github.io/微服务架构系列-基础篇-服务拆分的维度和拆分前的技术保障/

上篇分享学院君给大家介绍了微服务与单体应用的对比和优势，以及什么情况下适合使用微服务架构，对于大公司而言，可能之前已经进行过微服务重构，相应的底层服务都已经拆分，所以后续新功能开发会在微服务体系中进行迭代，而对于中小型公司，大部分情况是项目早期采用单体架构以便快速迭代和部署，当业务规模、团队规模成长到一定阶段，不得不需要通过微服务架构对服务进行拆分，对系统进行重构，即下面绿色曲线所代表的情况：

服务拆分的维度

如果已经决定要对系统进行微服务重构改造，首先要对耦合在单体应用中的服务进行拆分，那么服务拆分具体该怎么做呢？或者换句话说，服务拆分按照什么标准，以哪些维度作为划分依据？

这里主要有两种方式：

• 一种是从业务功能的角度进行纵向的垂直拆分，以电商网站为例，可以把常态购买看作一个服务模块，把特卖看看作一个服务模块，把拼团看作一个服务模块，把海外购看作一个服务模块，然后根据与相应模块关联的密切程度将对应的业务逻辑划分到具体的微服务中；
• 一种是从公用且功能独立的角度进行横向的水平拆分，还是以电商网站为例，上述所有服务模块都会用到用户、商品、交易这些公共功能，我们可以把这些模块也拆分为独立的微服务。

与服务拆分相关联的，还有公司组织架构的调整，原来大家可能都混在一起做开发，现在要根据拆分出来的服务为每个模块配对对应的开发人员，以便实现后续的独立开发、测试、部署和维护，另外可能还要涉及到数据库的拆分、缓存部署的调整。

服务拆分前的技术保障

前面我们多次强调过，伴随着服务的拆分和分布式的部署调用，使得系统架构的复杂性大大增加，为系统引入了很多新的问题，比如运维、配置、问题追踪与系统监控、远程服务发布与调用等，我们必须要做好这些配套的技术保障，才能开始操刀进行微服务重构。这些问题，也是从单体应用迁移到微服务架构时必将面临也必须解决的：