微服务的主要目的是将原本独立的系统拆分成多个小的,有独自进程运行的,同时这些小的服务单元之间通过RPC或者HTTP协议来相互通讯协作。每个独立的服务单元内部都有自己的数据存储、业务逻辑开发和自己的运维部署机制。我们在享受着微服务化后带来的灵活性便利的同时,对我们的运维和服务治理也提出了新的挑战。从早先单体应用中的代码依赖,变成了通信依赖。我们就不得不考虑以下问题,比如网络延迟、分布式事务、异步消息等等。
一、系统分类与演进
1. 统分类
我们的系统如果按照功能划分的话,大概有如下三类系统。
第一类是接口服务系统,这类系统是提供外部接口比如JSF(京东自研RPC框架)、HTTP接口、hession接口等,这些接口有读,有写,尤其是写接口,要考虑好写的幂等性操作,读天然是幂等的,做好防刷即可。
第二类是网页类系统,用户直接使用网页,那么网页上的数据区域来源,就要分清楚,一张网页上面的数据从好多个源头过来,每个源头下面都有多个系统来支撑,如果一份数据来自多个渠道,需不需合并,都是要考虑的。
第三类是任务类系统,比如我们常见的统计、数据同步等功能的系统。这类系统要考虑任务是热备还是冷备,多数都是热备,此种情况下就需要考虑好分布式是任务调度的问题,资源分配,计算的准确性等。
每种系统对应的梳理方式又是不同的。
2. 系统演进
系统架构变化也是与时俱进的,早期的单体系统跟现在大家践行的微服务化系统,在系统梳理上以及治理上也是完全不同。上图是一个系统架构的演进(图参照:《分布式服务框架》1.5章节)
二、梳理目的要搞清楚
每一年618和双11之前,备战开始,我们都要对所有的系统做一次梳理。那么每一次梳理的目的,就是要找出系统薄弱点。现在系统多了,系统里面的业务也变得复杂了。不过没有关系,还是那句老话,打蛇打七寸,利用二八原理。集中精力到最重要的环节。另外80%不是说就不管了,这里面的业务可以走限流或者降级处理,当然也是要梳理的。只不过要有轻重之分。
三、如何做
我们要从大的方面梳理出一个系统包含哪些功能,这些功能里面哪些是核心功能也叫做黄金功能。同时从小的方面,对已经梳理出的核心功能,我要再梳理出这些功能对应的流程上包含的各个节点。每个节点要找出强依赖和弱依赖。强依赖,是说少了这个依赖功能不能完成,那么就要准备容灾方案,也就是比如依赖的DB挂了,那么我们可以用开关切到MQ里面。弱依赖,则是不影响功能使用的依赖,比如插入ES记录日志,那么ES挂掉,我们直接降级就好。
1. 接口服务类系统
我们要梳理出提供的所有服务接口,找出其中的黄金接口,比如接口1是黄金接口,那么我们就要确保这个接口一定是可用的,如何保证,就是灾备。依赖资源比如redis集群,放两个机房,一个机房两套。总之这个接口是不可降级的,在不能降级的情况下,就要准备多套方案来确保接口1必须提供服务。
2. 网页类系统
网页类系统,比如首页,类目、展示区、导航栏,广告位,这些都不能挂,首页是一个网站的脸,企业的脸,一定不能丢脸。每个功能区域对应的信息都要有多级缓存,有托底数据,无论如何都要保证页面上是有内容的。
3. 任务类系统
对于任务类系统,一样,要有分布式worker,切不可以单点。解决方案可以利用zookeeper+定时任务,自己实现,也可以采用开源的方案比如Elastic-Job。
上面的三类系统,在我们现有的结构中均都已微服务化,我们开篇也突出了微服务治理的特点,网络延迟、分布式事务、异步消息。因此我们针对微服务的梳理也是从这几个方面入手。关键点,就是找出通讯依赖,确定是强依赖,还是弱依赖。
4. 核心功能的核心流程梳理
梳理出核心功能以后,我们就要开始梳理核心流程,流程的梳理要找出关键节点,比如下面这张图,只是作为举例使用,一些类名和和字段都用XX代替。关键节点,就是我们重点对待的,强依赖哪些资源,弱依赖哪些资源。使用不同颜色标注,比如深黄色表示强依赖,浅绿色表示弱依赖。
四、总结
上面描述的过程中,列举了系统的分类,系统的演进,流程的梳理。我们的最终目的就是要找出黄金功能,找出黄金流程,流程里面的强依赖和弱依赖。强依赖不可降级必须要有灾备方案。做到以上几点,确保梳理没有遗漏,无论系统如何演进与变化,我们的服务治理,618和双11的备战都能很好的完成!
作者:王新栋,目前就职于京东,一直从事京麦平台的架构设计与开发工作,熟悉各种开源软件架构。在web开发,架构优化上有较丰富实战经历。有多年在NIO领域的设计、开发经验,对HTTP、TCP长连接技术有深入研究与领悟,目前主要致力于移动与PC平台网关技术的优化与实现。
【本文来自51CTO专栏作者张开涛的微信公众号(开涛的博客),公众号id: kaitao-1234567】