微服务的主要目的是把原来独立的系统拆分成多个小的，有自己的进程运行，并且这些小的服务单元同时通过RPC或HTTP协议相互通信。每个独立的服务单元都有自己的数据存储、业务逻辑开发和运维部署机制。我们在享受微服务带来的灵活便捷的同时，也对我们的运维和服务治理提出了新的挑战。从早期单体应用中的代码依赖，变成了通信依赖。我们不得不考虑以下问题，比如网络延迟、分布式事务、异步消息等等。一、系统分类与演进1、总分类如果按照功能来划分我们的系统，大致有以下三类系统。第一类是接口服务系统。这类系统对外提供JSF（京东自研RPC框架）、HTTP接口、Hession接口等接口，这些接口包括读写，尤其是写接口，要写好幂等操作，读自然是幂等的，做好防刷就好了。第二种是网页系统。用户直接使用网页时，必须明确区分网页数据区的来源。网页上的数据来自多个来源，每个来源都有多个系统支持。如果一条数据来自多个来源，需要考虑是否需要合并。第三类是任务系统，比如我们常用的统计，数据同步等功能的系统。这类系统需要考虑任务是热备还是冷备。每个系统对应的梳理方式不同。2.系统演进系统架构的变化也与时俱进。早期的单体系统在系统梳理和治理上与现在大家实践的微服务系统是完全不同的。上图是一个系统架构的演化过程（见：《分布式服务框架》第1.5章）2.整理的目的要明确。每年618和双11之前，准备开始的时候，我们都要把所有的系统都梳理一遍。那么每次梳理的目的都是找出系统的薄弱环节。现在系统多了，系统里面的业务就变得复杂了。不过没关系，还是那句老话，打蛇打七寸，用二十八法则。专注于最重要的方面。另外80%也不容忽视。里面的业务可以限制或者降级。当然，也需要整理一下。这只是严重程度的问题。3、怎么做我们需要从大的角度梳理一个系统包含哪些功能，哪些功能是核心功能，也叫黄金功能。同时，从小的角度，对于梳理出来的核心功能，我再梳理一下这些功能对应的流程包含的各个节点。每个节点都需要找出强依赖和弱依赖。强依赖意味着没有这个依赖就无法完成功能，所以必须要准备容灾方案，即如果依赖的DB宕机了，那么我们可以用一个switch切换到MQ。弱依赖就是不影响功能使用的依赖，比如插入ES记录日志，然后ES挂了，我们直接降级就行了。1.接口服务体系我们需要对提供的所有服务接口进行梳理，找出其中的黄金接口。比如接口1是黄金接口，那我们一定要保证这个接口是可用的。如何保证是容灾。依靠redis集群等资源，放两个机房，一个机房两套。总之，这个接口不能降级。如果无法降级，则需要准备多种方案，保证接口1必须提供服务。2、网页系统网页系统，如首页、分类、展示区、导航栏、广告位等，不能发布。首页是网站的脸面，是企业的脸面，切不可丢人。每个功能区对应的信息必须有多级缓存和后台数据。不管怎样，都要保证页面上有内容。3、任务型系统与任务型系统一样，必须有分布式worker，不能有单点。方案可以自己使用zookeeper+定时任务实现，也可以使用Elastic-Job等开源方案。以上三类系统都在我们现有的架构中做了微服务化。我们在文章开头也强调了微服务治理的特点，比如网络延迟、分布式事务、异步消息等。所以我们在梳理微服务的时候也是从这些方面入手。关键是找出通信依赖，判断是强依赖还是弱依赖。4、核心功能的核心流程梳理完核心功能，我们就开始梳理核心流程。流程排序需要找出关键节点。例如，下图只是作为示例。一些类名和字段是用XX代替的。关键节点就是我们关注的重点，哪些资源是强依赖的，哪些资源是弱依赖的。使用不同的颜色来标记，比如深黄色代表强依赖，浅绿色代表弱依赖。4.小结在上面描述的过程中，列出了系统的分类、系统的演进、过程的梳理。我们的最终目标是找出黄金函数，找出黄金流程，以及流程中的强弱依赖关系。不能降级的强依赖必须有灾难恢复计划。做到以上几点，保证梳理无遗漏。不管系统如何演进和变化，我们的服务治理、618、双11的准备都可以很好的完成！作者：王新东，目前就职于京东，一直从事京麦平台架构设计和开发工作，熟悉各种开源软件架构。丰富的网站开发和架构优化经验。在NIO领域有多年的设计和开发经验，对HTTP和TCP长连接技术有深入的研究和理解。目前主要致力于移动和PC平台网关技术的优化和实施。【本文来自专栏作者张凯涛微信公众号（凯涛博客）公众号id：kaitao-1234567】点此查看作者更多好文
