上篇分享给大家介绍了微服务与单体应用的对比和优势，以及什么情况下适合使用微服务架构，对于大公司而言，可能之前已经进行过微服务重构，相应的底层服务都已经拆分，所以后续新功能开发会在微服务体系中进行迭代，而对于中小型公司，大部分情况是项目早期采用单体架构以便快速迭代和部署，当业务规模、团队规模成长到一定阶段，不得不需要通过微服务架构对服务进行拆分（这个服务拆分的时间节点就是我们上篇分享介绍的需要满足的三个条件是否成熟），对系统进行重构，即下面绿色曲线所代表的情况：
服务拆分的维度
如果已经决定要对系统进行微服务重构改造，首先要对耦合在单体应用中的服务进行拆分，那么服务拆分具体该怎么做呢？或者换句话说，服务拆分按照什么标准，以哪些维度作为划分依据？
这里主要有两种方式：
- 一种是从业务功能的角度进行纵向的垂直拆分，以电商网站为例，可以把常态购买看作一个服务模块，把特卖看看作一个服务模块，把拼团看作一个服务模块，把海外购看作一个服务模块，然后根据与相应模块关联的密切程度将对应的业务逻辑划分到具体的微服务中；
- 一种是从公用且功能独立的角度进行横向的水平拆分，还是以电商网站为例，上述所有服务模块都会用到用户、商品、交易这些公共功能，我们可以把这些模块也拆分为独立的微服务。
与服务拆分相关联的，还有公司组织架构的调整，原来大家可能都混在一起做开发，现在要根据拆分出来的服务为每个模块配对对应的开发人员，以便实现后续的独立开发、测试、部署和维护，另外可能还要涉及到数据库的拆分、缓存部署的调整。
服务拆分前的技术保障
前面我们多次强调过，伴随着服务的拆分和分布式的部署调用，使得系统架构的复杂性大大增加，为系统引入了很多新的问题，比如运维、配置、问题追踪与系统监控、远程服务发布与调用等，我们必须要做好这些配套的技术保障，才能开始操刀进行微服务重构。这些问题，也是从单体应用迁移到微服务架构时必将面临也必须解决的：
- 服务接口定义：对于单体应用来说，不同功能模块之间交互时，通常是以类库的方式来提供各个模块的功能；对于微服务来说，每个服务都运行在各自的进程之中，通过远程接口才能提供相应的服务，无论采用 HTTP 还是 RPC 协议，服务之间的调用都通过接口描述来约定，约定内容包括接口名、接口参数以及接口返回值。
- 服务发布与调用：单体应用由于部署在同一个包里，接口之间的调用属于进程内的调用；而拆分为微服务独立部署后，服务提供者该如何对外暴露自己的地址，服务调用者该如何查询所需要调用的服务的地址呢？这个时候你就需要一个注册中心，能够记录每个服务提供者的地址以供服务调用者查询。
- 服务监控方案：在微服务中需要一种通用的监控方案，能够覆盖业务埋点、数据收集、数据处理，最后到数据展示的全链路功能。
- 服务治理方案：拆分为微服务架构后，服务的数量变多了，依赖关系也变复杂了，当一个服务的性能有问题时，依赖的服务势必会受到影响，要如何通过熔断、限流、降级、负载均衡等方式将影响降到最低。
- 故障定位方案：在单体应用拆分为微服务之后，一次用户调用可能依赖多个服务，每个服务又部署在不同的节点上，如果用户调用出现问题，需要有一种解决方案能够将一次用户请求进行标记，并在多个依赖的服务系统中继续传递，以便串联所有路径，从而进行故障定位。
从下一篇开始，我们就将结合一个具体的微服务 RPC 框架来介绍上述问题是如何得到解决的。另外，微服务架构中，还可能要面临的一些问题是分库之后分布式数据库的访问和事务一致性，分布式缓存的设计和访问，以及公共配置中心的访问和设置，还有微服务拆分后部署和运维的复杂性增加，该如何解决等，这些都是我们在做微服务拆分的时候需要考虑到的，后续在高阶部分，将给大家介绍这些问题的解决方案。
