微服务化之服务拆分与服务发现

本文章为《互联网高并发微服务化架构实践》系列课程的第六篇。

目录

服务拆分的前提

服务拆分的时机

服务拆分的方法

服务拆分的规范

服务发现的选型

一、服务拆分的前提

说到微服务，服务拆分是绕不过去的话题，但是微服务不是说拆就能拆的，有很多的前提条件，需要完成前面几节所论述的部分。

首先要有一个持续集成的平台，使得服务在拆分的过程中，功能的一致性，这种一致性不能通过人的经验来，而需要经过大量的回归测试集，并且持续的拆分，持续的演进，持续的集成，从而保证系统时刻处于可以验证交付的状态，而非闭门拆分一段时间，最终谁也不知道功能最终究竟有没有bug，因而需要另外一个月的时间专门修改bug。

其次在接入层，API和UI要动静分离，API由API网关统一的管理，这样后端无论如何拆分，可以保证对于前端来讲，统一的入口，而且可以实现拆分过程中的灰度发布，路由分发，流量切分，从而保证拆分的平滑进行。而且拆分后的微服务之间，为了高性能，是不建议每次调用都进行认证鉴权的，而是在API网关上做统一的认证鉴权，一旦进入网关，服务之间的调用就是可信的。

其三对于数据库，需要进行良好的设计，不应该有大量的联合查询，而是将数据库当成一个简单的key-value查询，复杂的联合查询通过应用层，或者通过Elasticsearch进行。如果数据库表之间耦合的非常严重，其实服务拆分是拆不出来的。

其四要做应用的无状态化，只有无状态的应用，才能横向扩展，这样拆分才有意义。

二、服务拆分的时机

满足了服务拆分的前提之后，那先拆哪个模块，后拆哪个模块呢？什么情况下一个模块应该拆分出来呢？

微服务拆分绝非一个大跃进运动，由高层发起，把一个应用拆分的七零八落的，最终大大增加运维成本，但是并不会带来收益。

微服务拆分的过程，应该是一个由痛点驱动的，是业务真正遇到了快速迭代和高并发的问题，如果不拆分，将对于业务的发展带来影响，只有这个时候，微服务的拆分是有确定收益的，增加的运维成本才是值得的。

微服务解决的问题之一，就是快速迭代。

互联网产品的特点就是迭代速度快，一般一年半就能决出胜负，第一一统天下，第二被第一收购，其他死翘翘。所以快速上线，快速迭代，就是生命线，而且一旦成功就是百亿身家，所以无论付出多大运维成本，使用微服务架构都是值得的。

这也就是为什么大部分使用微服务架构的都是互联网企业，因为对于这些企业来讲收益明显。而对于很多传统的应用，半年更新一次，企业运营相对平稳，IT系统的好坏对于业务没有关键性影响，在他们眼中，微服务化改造带来的效果，还不如开发多加几次班。

微服务拆分时机一：提交代码频繁出现大量冲突

微服务对于快速迭代的效果，首先是开发独立，如果是一单体应用，几百人开发一个模块，如果使用GIT做代码管理，则经常会遇到的事情就是代码提交冲突。

同样一个模块，你也改，他也改，几百人根本没办法沟通。所以当你想提交一个代码的时候，发现和别人提交的冲突了，于是因为你是后提交的人，你有责任去merge代码，好不容易merge成功了，等再次提交的时候，发现又冲突了，你是不是很恼火。随着团队规模越大，冲突概率越大。

所以应该拆分成不同的模块，每十个人左右维护一个模块，也即一个工程，首先代码冲突的概率小多了，而且有了冲突，一个小组一吼，基本上问题就解决了。

每个模块对外提供接口，其他依赖模块可以不用关注具体的实现细节，只需要保证接口正确就可以。

微服务拆分时机二：小功能要积累到大版本才能上线，上线开总监级别大会

微服务对于快速迭代的效果，首先是上线独立。如果没有拆分微服务，每次上线都是一件很痛苦的事情。当你修改了一个边角的小功能，但是你不敢马上上线，因为你依赖的其他模块才开发了一半，你要等他，等他好了，也不敢马上上线，因为另一个被依赖的模块也开发了一半，当所有的模块都耦合在一起，互相依赖，谁也没办法独立上线，而是需要总监协调各个团队，大家开大会，约定一个时间点，无论大小功能，死活都要这天上线。

这种模式导致上线的时候，单次上线的需求列表非常长，这样风险比较大，可能小功能的错误会导致大功能的上线不正常，将如此长的功能，需要一点点check，非常小心，这样上线时间长，影响范围大。因而这种的迭代速度快不了，顶多一个月一次就不错了。

服务拆分后，在接口稳定的情况下，不同的模块可以独立上线。这样上线的次数增多，单次上线的需求列表变小，可以随时回滚，风险变小，时间变短，影响面小，从而迭代速度加快。

对于接口要升级部分，保证灰度，先做接口新增，而非原接口变更，当注册中心中监控到的调用情况，发现接口已经不用了，再删除。

微服务解决的问题之二，就是高并发。

互联网一个产品的特点就是在短期内要积累大量的用户，这甚至比营收和利润还重要，如果没有大量的用户基数，融资都会有问题。

因而对于并发量不大的系统，进行微服务化的驱动力差一些，如果只有不多的用户在线，多线程就能解决问题，最多做好无状态化，前面部署个负载均衡，单体应用部署多份。

微服务拆分时机三：横向扩展流程复杂，主要业务和次要业务耦合

单体应用无状态化之后，虽然通过部署多份，可以承载一定的并发量，但是资源非常浪费。因为有的业务是需要扩容的，例如下单和支付，有的业务是不需要扩容的，例如注册。如果一起扩容，消耗的资源可能是拆分后的几倍，成本可能多出几个亿。而且由于配置复杂，在同一个工程里面，往往在配置文件中是这样组织的，这一块是这个模块的，下一块是另一个模块的，这样扩容的时候，一些边角的业务，也是需要对配置进行详细审核，否则不敢贸然扩容。

微服务拆分时机四：熔断降级全靠if-else

在高并发场景下，我们希望一个请求如果不成功，不要占用资源，应该尽快失败，尽快返回，而且希望当一些边角的业务不正常的情况下，主要业务流程不受影响。这就需要熔断策略，也即当A调用B，而B总是不正常的时候，为了让B不要波及到A，可以对B的调用进行熔断，也即A不调用B，而是返回暂时的fallback数据，当B正常的时候，再放开熔断，进行正常的调用。

有时候为了保证核心业务流程，边角的业务流程，如评论，库存数目等，人工设置为降级的状态，也即默认不调用，将所有的资源用于大促的下单和支付流程。

如果核心业务流程和边角业务流程在同一个进程中，就需要使用大量的if-else语句，根据下发的配置来判断是否熔断或者降级，这会使得配置异常复杂，难以维护。

如果核心业务和边角业务分成两个进程，就可以使用标准的熔断降级策略，配置在某种情况下，放弃对另一个进程的调用，可以进行统一的维护。

三、服务拆分的方法

好了，当你觉得要将一个程序的某个部分拆分出来的时候，有什么方法可以保障平滑吗？

首先要做的，就是原有工程代码的标准化，我们常称为“任何人接手任何一个模块都能看到熟悉的面孔”

例如打开一个 java 工程，应该有以下的package：

API接口包：所有的接口定义都在这里，对于内部的调用，也要实现接口，这样一旦要拆分出去，对于本地的接口调用，就可以变为远程的接口调用

访问外部服务包：如果这个进程要访问其他进程，对于外部访问的封装都在这里，对于单元测试来讲，对于这部分的Mock，可以使得不用依赖第三方，就能进行功能测试。对于服务拆分，调用其他的服务，也是在这里。

数据库DTO：如果要访问数据库，在这里定义原子的数据结构

访问数据库包：访问数据库的逻辑全部在这个包里面

服务与商务逻辑：这里实现主要的商业逻辑，拆分也是从这里拆分出来。

外部服务：对外提供服务的逻辑在这里，对于接口的提供方，要实现在这里。

另外是测试文件夹，每个类都应该有单元测试，要审核单元测试覆盖率，模块内部应该通过Mock的方法实现集成测试。

接下来是配置文件夹，配置profile，配置分为几类：

内部配置项(启动后不变，改变需要重启)

集中配置项(配置中心，可动态下发)

外部配置项(外部依赖，和环境相关)

当一个工程的结构非常标准化之后，接下来在原有服务中，先独立功能模块 ，规范输入输出，形成服务内部的分离。在分离出新的进程之前，先分离出新的jar，只要能够分离出新的jar，基本也就实现了松耦合。

接下来，应该新建工程，新启动一个进程，尽早的注册到注册中心，开始提供服务，这个时候，新的工程中的代码逻辑可以先没有，只是转调用原来的进程接口。

为什么要越早独立越好呢？哪怕还没实现逻辑先独立呢？因为服务拆分的过程是渐进的，伴随着新功能的开发，新需求的引入，这个时候，对于原来的接口，也会有新的需求进行修改，如果你想把业务逻辑独立出来，独立了一半，新需求来了，改旧的，改新的都不合适，新的还没独立提供服务，旧的如果改了，会造成从旧工程迁移到新工程，边迁移边改变，合并更加困难。如果尽早独立，所有的新需求都进入新的工程，所有调用方更新的时候，都改为调用新的进程，对于老进程的调用会越来越少，最终新进程将老进程全部代理。

接下来就可以将老工程中的逻辑逐渐迁移到新工程，由于代码迁移不能保证逻辑的完全正确，因而需要持续集成，灰度发布，微服务框架能够在新老接口之间切换。

最终当新工程稳定运行，并且在调用监控中，已经没有对于老工程的调用的时候，就可以将老工程下线了。

四、服务拆分的规范

微服务拆分之后，工程会比较的多，如果没有一定的规范，将会非常混乱，难以维护。

首先人们经常问的一个问题是，服务拆分之后，原来都在一个进程里面的函数调用，现在变成了A调用B调用C调用D调用E，会不会因为调用链路过长而使得相应变慢呢？

服务拆分的规范一：服务拆分最多三层，两次调用

服务拆分是为了横向扩展，因而应该横向拆分，而非纵向拆成一串的。也即应该将商品和订单拆分，而非下单的十个步骤拆分，然后一个调用一个。

纵向的拆分最多三层：

基础服务层：用于屏蔽数据库，缓存层，提供原子的对象查询接口，有这一层，为了数据层做一定改变的时候，例如分库分表，数据库扩容，缓存替换等，对于上层透明，上层仅仅调用这一层的接口，不直接访问数据库和缓存。

组合服务层：这一层调用基础服务层，完成较为复杂的业务逻辑，实现分布式事务也多在这一层

Controller层：接口层，调用组合服务层对外

服务拆分的规范二：仅仅单向调用，严禁循环调用

微服务拆分后，服务之间的依赖关系复杂，如果循环调用，升级的时候就很头疼，不知道应该先升级哪个，后升级哪个，难以维护。

因而层次之间的调用规定如下：

基础服务层主要做数据库的操作和一些简单的业务逻辑，不允许调用其他任何服务。

组合服务层，可以调用基础服务层，完成复杂的业务逻辑，可以调用组合服务层，不允许循环调用，不允许调用Controller层服务

Controller层，可以调用组合业务层服务，不允许被其他服务调用

如果出现循环调用，例如A调用B，B也调用A，则分成Controller层和组合服务层两层，A调用B的下层，B调用A的下层。也可以使用消息队列，将同步调用，改为异步调用。

服务拆分的规范三：将串行调用改为并行调用，或者异步化

如果有的组合服务处理流程的确很长，需要调用多个外部服务，应该考虑如何通过消息队列，实现异步化和解耦。

例如下单之后，要刷新缓存，要通知仓库等，这些都不需要再下单成功的时候就要做完，而是可以发一个消息给消息队列，异步通知其他服务。

而且使用消息队列的好处是，你只要发送一个消息，无论下游依赖方有一个，还是有十个，都是一条消息搞定，只不过多几个下游监听消息即可。

对于下单必须同时做完的，例如扣减库存和优惠券等，可以进行并行调用，这样处理时间会大大缩短，不是多次调用的时间之和，而是最长的那个系统调用时间。

服务拆分的规范四：接口应该实现幂等

微服务拆分之后，服务之间的调用当出现错误的时候，一定会重试，但是为了不要下两次单，支付两次，需要所有的接口实现幂等。

幂等一般需要设计一个幂等表来实现，幂等表中的主键或者唯一键可以是transaction id，或者business id，可以通过这个id的唯一性标识一个唯一的操作。

也有幂等操作使用状态机，当一个调用到来的时候，往往触发一个状态的变化，当下次调用到来的时候，发现已经不是这个状态，就说明上次已经调用过了。

状态的变化需要是一个原子操作，也即并发调用的时候，只有一次可以执行。可以使用分布式锁，或者乐观锁CAS操作实现。

服务拆分的规范五：接口数据定义严禁内嵌，透传

微服务接口之间传递数据，往往通过数据结构，如果数据结构透传，从底层一直到上层使用同一个数据结构，或者上层的数据结构内嵌底层的数据结构，当数据结构中添加或者删除一个字段的时候，波及的面会非常大。

因而接口数据定义，在每两个接口之间约定，严禁内嵌和透传，即便差不多，也应该重新定义，这样接口数据定义的改变，影响面仅仅在调用方和被调用方，当接口需要更新的时候，比较可控，也容易升级。

服务拆分的规范六：规范化工程名

微服务拆分后，工程名非常多，开发人员，开发团队也非常多，如何让一个开发人员看到一个工程名，或者jar的名称，就大概知道是干什么的，需要一个规范化的约定。

例如出现pay就是支付，出现order就是下单，出现account就是用户。

再如出现compose就是组合层，controller就是接口层，basic就是基础服务层。

出现api就是接口定义，impl就是实现。

pay-compose-api就是支付组合层接口定义。

account-basic-impl就是用户基础服务层的实现。

五、服务发现的选型

微服务拆分后，服务之间的调用需要服务发现和注册中心进行维护。也能主流的有几种方法。

第一是dubbo，Dubbo是SOA架构的微服务框架的标准，已经被大量使用，虽然中间中断维护过一段时间，但是随着微服务的兴起，重新进行了维护，是很多熟悉Dubbo RPC开发人员的首选。

第二种是springcloud，springcloud为微服务而生，在dubbo已经没有人维护的情况下，推出了支撑微服务的成熟框架。

dubbo vs. springcloud的对比，dubbo更加注重服务治理，原生功能不够全面，而springcloud注重整个微服务生态，工具链非常全面。

springcloud可定制性强，通过各种组件满足各种微服务场景，使用springboot统一编程模型，能够快速构建应用，基于注解，使用方便，但是学习门槛比较高。

Dubbo注册到zookeeper里面的是接口，而springcloud注册到Eureka或者consul里面的是实例，在规模比较小的情况下没有分别，但是规模一旦大了，例如实例数目万级别，接口数据就算十万级别，对于zookeeper中的树规模比较大，而且zookeeper是强一致性的，当一个节点挂了的时候，节点之间的数据同步会影响线上使用，而springcloud就好很多，实例级别少一个量级，另外consul也非强一致的。

第三是kubernetes，Kubernetes虽然是容器平台，但是他设计出来，就是为了跑微服务的，因而提供了微服务运行的很多组件。

很多springcloud可以做的事情，kubernetes也有相应的机制，而且由于是容器平台，相对比较通用，可以支持多语言，对于业务无侵入，但是也正因为是容器平台，对于微服务的运行生命周期的维护比较全面，对于服务之间的调用和治理，比较弱，service只能满足最最基本的服务发现需求。

因而实践中使用的时候，往往是kubernetes和springcloud结合使用，kubernetes负责提供微服务的运行环境，服务之间的调用和治理，由springlcoud搞定。

第四是service mesh，service mesh一定程度上弥补了kubernetes对于服务治理方面的不足，对业务代码0侵入，将服务治理下沉到平台层，是服务治理的一个趋势。

然而service mesh需要使用单独的进程进行请求转发，性能还不能让人满意，另外社区比较新，成熟度不足，暂时没有达到大规模生产使用的标准。

本文转载自公众号： 刘超的通俗云计算

原文链接： https://mp.weixin.qq.com/s/mcBdtqBRQbY4D5i6G7o-7g

关于Wise2C睿云智合

深圳睿云智合科技有限公司成立于2012年，总部位于深圳，并分别在成都、深圳设立了研发中心，北京、上海设立了分支机构，核心骨干人员全部为来自金融、科技行业知名企业资深业务专家、技术专家。早期专注于为中国金融保险等大型企业提供创新技术、电子商务、CRM等领域专业咨询服务。

自2016年始，在率先将容器技术引进到中国保险行业客户后，公司组建了专业的容器技术产品研发和实施服务团队，旨在帮助中国金融行业客户将容器创新技术应用于企业信息技术支持业务发展的基础能力改善与提升，成为中国金融保险行业容器技术服务领导品牌。

此外，凭借多年来在呼叫中心领域的业务经验与技术积累，睿云智合率先在业界推出基于开源软交换平台FreeSwitch的微服务架构多媒体数字化业务平台，将语音、视频、webchat、微信、微博等多种客户接触渠道集成，实现客户统一接入、精准识别、智能路由的CRM策略，并以容器化治理来支持平台的全应用生命周期管理，显著提升了数字化业务处理的灵活、高效、弹性、稳定等特性，为帮助传统企业向“以客户为中心”的数字化业务转型提供完美的一站式整体解决方案。