服务化带来的问题，我们是如何解决的
聊起微服务，服务化，很多朋友都了解服务化带来的好处，简单罗列几点：
- 屏蔽与自身业务无关技术细节（比如很多业务需要查询用户信息，服务化之前所有业务场景都通过DAO去查询用户信息，随着业务发展，并发量增加，用户信息需要加缓存，这样所有业务场景都需要关注缓存，服务化之后，缓存由各自服务维护，其他服务调用相关服务即可，不需要关注类似的缓存问题）
- 数据隔离，不同的服务对应不同数据库数据表，服务之间获取数据的方式通过服务调用的方式
- 降低维护成本（随着业务量增长，业务越来越复杂，开发人员越来越多） 1，业务边界代码边界清晰（单体架构中不同的业务，代码耦合严重，随着业务量增长，业务复杂后，一个小功能点的修改就可能影响到其他业务点，开发质量不可控，测试需要回归，成本持续提高） 2，显著减少代码冲突
- 可复用，显著减少代码拷贝现象
服务化确实带来不少好处，那么服务化有没有什么问题呢？答案是肯定的！下面分享一下我们曾经在服务化过程中经历的问题：
- 服务雪崩
- 链路过长，问题难定位
- 服务调用关系错综复杂
- 服务化过程数据库拆分，数据迁移
- 数据一致性问题
- 灰度发布
- 服务网关
- 应对突发流量
- 秒杀系统设计
我们是如何解决的？
1. 服务雪崩
服务化后，调用链路变长。一个服务出现性能问题就会影响到依赖它的服务。比如，A依赖B，B依赖C，当C出现性能问题（响应慢或者服务不可用），在高并发场景下，B调用C会频繁超时，期间线程无法及时释放（要等到timeout才能释放），很快B也会因为线程耗尽导致服务无法响应。性能问题层层传递，很快A也会出问题。连锁反应就是这样发生的。这也是我们平常所说的雪崩效应的案例。
那么我们是如何解决的呢？
- 异步通信 首先考虑一下，你的场景是否适合用异步方式通信，如何适合就可以采用消息队列，这样可以有效避免同步调用线程阻塞问题。
- 熔断隔离 如果更适合同步调用，可以考虑熔断。熔断是一种降级手段，当服务不可用时，用来避免连锁故障，雪崩效应。单位时间请求超时次数或者错误次数达到一定阈值，服务调用方开启熔断，请求由服务调用方直接返回，不会发送到服务提供方。熔断的意义在于：1，（最重要的意义）对于服务调用方，熔断开启后，请求在服务调用方可以快速失败（FAIL FAST），从而避免线程持续等待，线程池线程和CPU资源逐渐耗尽，进而导致服务无响应，问题层层传递，最终引发全链路崩溃。2，对于服务提供方，熔断后，不会再接到请求，访问压力暂时得到缓解，避免仍旧存活的服务被压垮，保护服务提供方。常用的开源熔断组件有hystrix ，resilience4j，alibaba sentinel等。
至于隔离，指同一JVM内部线程的隔离。按照业务类型，对同一JVM内部的线程做分组，不同的线程组服务于不同的业务，不同的类和方法。线程组之间相互隔离，避免相互干扰。
- 数据冗余 服务提供方故障后，无法提供数据给调用方，为了提高系统整体健壮性，可以在关键服务冗余（暂存）其依赖服务的数据，当依赖的服务发生故障后，仍然可以暂时使用自己冗余的数据。数据冗余可以结合熔断fallback使用，可以显著提高系统健壮性和用户体验。
- 部署隔离 相同业务模块，to C端服务和内部服务隔离部署，避免互相影响。
2. 链路过长，问题难定位
服务化之后调用链路会变长，定位问题也会更加困难。这时我们需要一个全链路监控工具帮助我们监控服务以及快速定位系统问题。全链路APM监控，部分大型互联网公司会自己研发，绝大多数公司还是选用开源或者收费SAAS服务，这里仅以曾经用过的Pinpoint为例，Pinpoint基于JAVA，利用字节码增强技术，对服务零侵入，以traceID串联各个服务，已Plugin的方式支持不同API和中间件的监控，灵活方便。
上图是一个请求的调用栈，我们可以清晰看到一次请求调用了哪些服务和方法以及各个环节的耗时，以及发生在哪个节点。如果发生错误，会显示为红色，错误原因也会直接显示出来。这样通过APM系统我们就能轻松定位线上性能问题和错误了！
3. 服务调用关系错综复杂
服务化之后，因为服务多了，调用关系也会越来越复杂，以至于很多工程师不清楚服务间的依赖和调用关系，之后的系统维护过程也会更加艰巨！幸好，一般APM工具都解决了这个问题，还是以Pinpoint为例，他提供了服务关系拓扑图（请看下图），服务，数据库，缓存中间件等等的调用关系一览无余，通过它也能及时发现循环调用问题并尽快处理！
4. 服务化过程数据库拆分，数据迁移
5. 数据一致性问题
6. 灰度发布
7. 服务网关
8. 应对突发流量
9. 秒杀系统设计
由于篇幅原因，问题4到9的解决方案会放在以后的文章中推给大家。大家有任何问题和建议，请随时留言，我尽快回复各位！感谢大家关注！