如何用“二八原理”对微服务做系统梳理,找出黄金流程

作者:王新栋 目前就职于京东,一直从事京麦平台的架构设计与开发工作,熟悉各种开源软件架构。在web开发,架构优化上有较丰富实战经历。有多年在NIO领域的设计、开发经验,对HTTP、TCP长连接技术有深入研究与领悟,目前主要致力于移动与PC平台网关技术的优化与实现。

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

1、系统分类与演进
1.1 统分类

我们的系统如果按照功能划分的话,大概有如下三类系统。

第一类是接口服务系统,这类系统是提供外部接口比如JSF(京东自研RPC框架)、HTTP接口、hession接口等,这些接口有读,有写,尤其是写接口,要考虑好写的幂等性操作,读天然是幂等的,做好防刷即可。

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

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

1.2 系统演进

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

2、梳理目的要搞清楚

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

3、如何做

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

3.1、接口服务类系统

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

3.2、网页类系统

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

3.3、任务类系统

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

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

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

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

4、总结

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

----------------------------------END----------------------------------

下面的内容同样精彩

点击图片即可阅读

深度解析京东微服务组件平台

京东微服务平台架构解密

京东技术 ∣关注技术的公众号

原文发布于微信公众号 - 京东技术(jingdongjishu)

原文发表时间:2018-05-25

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏腾讯大讲堂的专栏

【大系统小做】——理论篇

大系统小做是什么? 我们先看一个简单的例子: 舞厅要装设多色灯,有2种实现方案: ? 思考:它们各有什么优缺点? 方案1: 优点:整体性强; 缺点: 系统可靠性...

2199
来自专栏向治洪

蘑菇街直播架构

直播简介 直播最主要的特点就是实时性与互动性,这也是直播与点播之间的差别所在,它可以实时将主播端的视频信息以较低延迟传输到观众端,与此同时,观众可以通过群聊或者...

2818
来自专栏web前端教室

【流行】现在前端流行的技术是哪几种?

其实从根本上来讲,前端开发过去、现在、将来,至少在可能预见的将来,有且只有三种技术,就是html、css、js,其它的都是围绕着这三种技术在打转。

1163
来自专栏C语言小白到大神

C语言实现动态菜单,智慧的C语言,零基础也可以学会

学习源于兴趣,源于快乐,源于追求,在这里你将收获更多的学习乐趣。在这里你将用代码将未来编写为现实。

160
来自专栏Rainbond开源「容器云平台」

【微服务干货系列】Yelp公司总结的微服务架构的实践经验

902
来自专栏C语言小白到大神

C语言实现动态菜单,智慧的C语言,零基础也可以学会

学习源于兴趣,源于快乐,源于追求,在这里你将收获更多的学习乐趣。在这里你将用代码将未来编写为现实。

550
来自专栏EAWorld

应用容器云:接过Java EE的枪

主要大纲: 一、回顾Java EE的发展 二、揭露Java EE的根本性缺陷 三、从Java EE的角度看应用容器云 四、对未来的展望 老实说,今天的观点如果放...

2996
来自专栏云计算D1net

亚马逊云平台的迁移过程

最近3个月变化很多,离开呆了5年多的北京,开始英国的工作和生活。到这之后基本在做系统向亚马逊云平台的迁移,踩了不少坑,收获也很多。由于系统的迁移涉及各个常见的架...

3409
来自专栏灯塔大数据

12种免费思维导图工具助你成为结构化思维专家(下)

如果昨天的文章你觉得颇受启发,现在就看看这些思维导图工具吧。 以下列出的大部分工具都是免费的。当然,付费的思维导图工具会有更多功能,但是这些免费的也完全能够满...

2725
来自专栏Forrest随想录

如何打造一个以应用为核心的运维体系

在前面《有了CMDB,为什么还要应用配置管理》一文中,描述了CMDB和应用配置管理的关系,这里面提到了非常核心的一个概念:应用,。但是,上篇中更多的是从运维的角...

782

扫描关注云+社区