微服务的主要目的是将原本独立的系统拆分成多个小的，有独自进程运行的，同时这些小的服务单元之间通过RPC或者HTTP协议来相互通讯协作。每个独立的服务单元内部都有自己的数据存储、业务逻辑开发和自己的运维部署机制。我们在享受着微服务化后带来的灵活性便利的同时，对我们的运维和服务治理也提出了新的挑战。从早先单体应用中的代码依赖，变成了通信依赖。我们就不得不考虑以下问题，比如网络延迟、分布式事务、异步消息等等。

1、系统分类与演进

1.1、系统分类

我们的系统如果按照功能划分的话，大概有如下三类系统。
第一类是接口服务系统，这类系统是提供外部接口比如JSF(京东自研RPC框架)、HTTP接口、hession接口等，这些接口有读，有写，尤其是写接口，要考虑好写的幂等性操作，读天然是幂等的，做好防刷即可。

第二类是网页类系统，用户直接使用网页，那么网页上的数据区域来源，就要分清楚，一张网页上面的数据从好多个源头过来，每个源头下面都有多个系统来支撑，如果一份数据来自多个渠道，需不需合并，都是要考虑的。

第三类是任务类系统，比如我们常见的统计、数据同步等功能的系统。这类系统要考虑任务是热备还是冷备，多数都是热备，此种情况下就需要考虑好分布式是任务调度的问题，资源分配，计算的准确性等。
每种系统对应的梳理方式又是不同的。

1.2、系统演进

系统演进图.png

系统架构变化也是与时俱进的，早期的单体系统跟现在大家践行的微服务化系统，在系统梳理上以及治理上也是完全不同。上图是一个系统架构的演进（图参照：《分布式服务框架》1.5章节）

2、梳理目的要搞清楚

每一年618和双11之前，备战开始，我们都要对所有的系统做一次梳理。那么每一次梳理的目的，就是要找出系统薄弱点。现在系统多了，系统里面的业务也变得复杂了。不过没有关系，还是那句老话，打蛇打七寸，利用二八原理。集中精力到最重要的环节。另外80%不是说就不管了，这里面的业务可以走限流或者降级处理，当然也是要梳理的。只不过要有轻重之分。

3、如何做

我们要从大的方面梳理出一个系统包含哪些功能，这些功能里面哪些是核心功能也叫做黄金功能。同时从小的方面，对已经梳理出的核心功能，我要再梳理出这些功能对应的流程上包含的各个节点。每个节点要找出强依赖和弱依赖。强依赖，是说少了这个依赖功能不能完成，那么就要准备容灾方案，也就是比如依赖的DB挂了，那么我们可以用开关切到MQ里面。弱依赖，则是不影响功能使用的依赖，比如插入ES记录日志，那么ES挂掉，我们直接降级就好。

3.1、接口服务类系统

接口服务类型系统.png

我们要梳理出提供的所有服务接口，找出其中的黄金接口，比如接口1是黄金接口，那么我们就要确保这个接口一定是可用的，如何保证，就是灾备。依赖资源比如redis集群，放两个机房，一个机房两套。总之这个接口是不可降级的，在不能降级的情况下，就要准备多套方案来确保接口1必须提供服务。

3.2、网页类系统

网页类系统.png

网页类系统，比如首页，类目、展示区、导航栏，广告位，这些都不能挂，首页是一个网站的脸，企业的脸，一定不能丢脸。每个功能区域对应的信息都要有多级缓存，有托底数据，无论如何都要保证页面上是有内容的。

3.3、任务类系统

任务类系统.png

对于任务类系统，一样，要有分布式worker，切不可以单点。解决方案可以利用zookeeper+定时任务，自己实现，也可以采用开源的方案比如Elastic-Job,

上面的三类系统，在我们现有的结构中均都已微服务化，我们开篇也突出了微服务治理的特点，网络延迟、分布式事务、异步消息。因此我们针对微服务的梳理也是从这几个方面入手。关键点，就是找出通讯依赖，确定是强依赖，还是弱依赖。

3.4、核心功能的核心流程梳理

梳理出核心功能以后，我们就要开始梳理核心流程，流程的梳理要找出关键节点，比如下面这张图，只是作为举例使用，一些类名和和字段都用XX代替。关键节点，就是我们重点对待的，强依赖哪些资源，弱依赖哪些资源。使用不同颜色标注，比如深黄色表示强依赖，浅绿色表示弱依赖。

核心流程梳理参照图.png

4、总结

上面描述的过程中，列举了系统的分类，系统的演进，流程的梳理。我们的最终目的就是要找出黄金功能，找出黄金流程，流程里面的强依赖和弱依赖。强依赖不可降级必须要有灾备方案。做到以上几点，确保梳理没有遗漏，无论系统如何演进与变化，我们的服务治理，618和双11的备战都能很好的完成！

转载请注明出处，并附上链接http://www.jianshu.com/p/ca7522d88e20