AWSomeDay 中体会的微服务治理

1. 服务治理这块，根据经验，有三个需要注意的。一是接口的统一性，当公司发展到几百人的时候，如果没有接口规范，那效率马上就会下降。之前可以像游 击队一样打，但人多了之后，还是像正规军一样战斗力会比较强。二是容错一定要做好，这块可以参考Netflix开源的几个组件。容错如果没有做好，在服务 化这样的系统里，很可能会造成雪崩效应。容错的方案也有很多，比如限流、回退、隔离、熔断。三是监控，在微服务出错之后，团队需要快速定位出错的位置和原 因。

2. 服务治理这块，阿里巴巴有个不错的框架Dubbo， 已经开源。抛开服务治理不说，我来举个服务化的反例，Facebook内部是反服务化的。Facebook所有的代码只有两个库，并且所有的发布都是同时 进行的，每个机器都一模一样。所以Facebook可以做到零运维，并且服务根本没有版本的概念。阿里巴巴现在的服务也准备往回收，在没有服务和过多的服 务之间找到一个平衡点。

3. 服务方需要知道服务会被多少人调用，被哪些业务调用，每个时间点上的状态是怎么样的。一个经验是为每个服务都起一个名字，当出现问题时，可以快速定位到。另外，阿里的eagleye和点评的CAT监控系统，支持对服务调用链和依赖关系进行可视化监控，可以参考学习。

4. 微服务中，服务的测试是一个非常大的挑战。服务和服务之间会存在依赖，所以环境的搭建可能就会涉及到多个团队，这个时候就需要能快速部署环境，当然现在比较推荐的方案是容器。

5. 微服务，其实对应的应该是微业务，是为了适应业务的多变／面向最终用户的个性化需求。而微服务的力度，很大程度上是取决于完成一项业务所要设计的 数据存储所在的区域。微服务的监控，和原来的服务监控力度应该是类似的，包括业务、应用、系统多个层次，日志、Metrics、调用链、告警等多个维度。

6. 提到监控，大家一般都是从系统、应用等层面去考虑。我这里抛一个思路给大家：舆情监控。很多时候，当系统出问题的时候，我们并不是在监控那里得到 消息，而是从微博、微信等渠道中收到用户反馈（XX系统真垃圾，又挂了之类…..）。我们努力了几年了，就是想让我们的监控系统能在舆论之前监测到系统的 异常状态，但很难，所以现在我们也在重点考虑舆情监控。