脚踏实地,方能仰望星空——从单体应用到微服务的进化之路

1

今天想跟大家聊一聊最近在互联网上非常火的技术架构的核心,微服务和容器化。

我会分析高校信息化是如何从单体应用演化到微服务领域,来挖掘背后这一轮架构演化的原始驱动力是什么,演化到微服务之后又能够为高校信息化带来什么样的正面和积极的影响,以这个角度来进行讲述。

首先来明确一下,新的条件下我们的应用系统面临的新的挑战是什么,在这种新的挑战之下我们的应用系统的现状又是什么,然后从架构演化的角度来去挖掘架构产生问题的根源在哪里,最后我们提出联奕在校园信息化用新技术来重构业务系统的一整套新的解决方案是什么样的。

2

 

首先从四个字开始,就是“消费升级”。

过去的一到两年里,“消费升级”这四个字在各行各业被广泛谈论。在联奕看来,所谓消费升级,就是在用户的基本需求得到满足的前提下,作为一个应用和服务的提供商,如何更好地挖掘连用户都不知道的潜在需求,把系统打造地更好,来满足越来越挑剔的用户的过程。

回归到软件领域,我们该如何迎合这一波“消费升级”?

3

时间关系我主要谈两点。

第一是用户体验

用户体验不是一个新概念,在过去的两年里,这波风潮从互联网行业一直刮到企业级开发。大家把“用户体验”摆在了一个非常高的战略层面来看待,这在以前是不可想象的。以前我们通过一个截图就能分辨出,什么是业务系统,什么是互联网产品。甚至有设计师A在评价设计师B的作品的时候说,“你这个产品设计得非常low,看起来跟业务系统一样”,以这种说法来嘲笑整个业务系统。而经过这两年的改善,我们很高兴看到的一个局面是,联奕还有其他的友商都在“用户体验”上倾注了大量人力物力,使得业务系统不论是在UI还是UE或者是在用户的功能贴合上都取得了长足的进步。

 

第二点是“高可用”三个字,这也是我更想强调的。

假设我们在用户体验上已经得到了非常大的改进,但如果系统在“高可用”方面并没有得到有效解决的话,那就意味着用户得到的只是一个漂亮、好看但是脆弱的系统。如果业务系统没有在“高可用”方面做好准备,这个情况不是我们想看到的。今天我所有的解决方案都是围绕“高可用”这块。

 

那么对“高可用”构成挑战的因素有哪些?

4

第一种因素是需求变化快。

之前我们在做系统时经常会出现的一个问题是,我们可以花大量的时间去做需求调研,分析完了所有需求之后,我们再奔着统一目标去做开发。而现在这种情况下几乎不太可能,因为用户大量的需求都是要通过线上的迭代来完成,并不是在一开始就能把需求收集得非常好。所以说,任何需求的变化,只要做线上迭代,就意味着对线上系统的可用性要做非常高的规划,否则是极容易出问题的。

 

第二个因素是用户规模大。

随着各种系统的功能性越来越多,我们的业务系统不再仅限于为某一个比较窄的受众里面解决他们的业务需求,我们需要站在更高的业务层面去布局。这也就意味着,我们的用户规模在变大,传统的业务系统在高并发之前没有高并发的需求,而现在问题变得非常突出。

 

第三个因素是使用频率高

移动端迅速的普及造成人机交互的时间从原来的几分钟几小时变成了现在要分分钟在线的状态,用户对系统的要求是要做到实时交互。

 

这三点就是对“高可用”构成挑战的因素。

 

接下来聊一下现在信息化的现状是什么。

5

6

第一, 敏捷交付受到极大考验

有时候我们会接到客户提的要求,比如对线上的系统做一次功能的更新,我们评估完需求后,开发报给我的时间是1天,20行代码30行代码非常容易搞定,需求上线之前到测试部门这边,测试部门报给我,这个功能要上线的话,可能要2-3周。这是个非常恐怖的数字,开发只要1天,测试需要2-3周。这就意味着我们在敏捷交付这块出了问题,为什么要花费大量的时间来做测试呢,后面我会讲到。

 

第二,并发压力没有得到根本的解决

在高校信息化里,选课业务是个比较典型的例子,在比较短的单位时间内,所有的用户比较集中地对系统进行访问,在各方面对系统造成冲击。之前没有在高并发方面做储备的时候,作为学校的管理方,只能被迫地选择去制造一些人为的障碍,比如分年级、分专业选课,通过制度去规避高并发的压力。而从软件开发的角度来说,我认为这是不应该出现的情况。

 

第三,可伸缩性差

所有的运维在伸缩性这块都是滞后于并发来临和流量洪峰时间段的。

 

明确了现状之后,我们来分析为什么在架构上会出现这样的问题。

 

这是一个非常典型的单体应用的架构。

7

上层客户端其实就是浏览器,浏览器把请求提交到nginx(也就是反向代理层),反向代理层通过均衡负载的算法把流量分发到底下的web-server(web集群),web层又跟db层之间有一些数据的交互,从而串起来整条线,这就是标准单体应用的架构。

单体应用的架构其实本身而言并没有太大的问题,包括一些像谷歌这样的非常庞大的广告系统也依然采用的是这种单体应用架构,那么真正出问题在哪里呢,我们可以把目光锁定在web-server这一层去尝试分析它的内部板块。

第一是代码耦合的问题

8

这是一个非常典型的应用,业务线分为ABC三块,都要根据某些需求来访问用户的数据,获取用户的权限或者获取用户的信息。在传统的单体应用架构底下,处理的方式基本都是代码解耦的方式,也就是说,所有关于对user数据访问的代码其实是属于复制在三条业务线里面的,这就会造成代码之间的耦合。代码的耦合会出现什么问题呢,随着系统进一步的演化,可能在user db数据库这一层会受到非常大的压力,迫于无奈我们必须要在数据库这一层增加一个cache层,也就是一个缓冲区,来试图降低整个数据库IO的压力。加了cache之后,因为上层的代码耦合,ABC三条线都要对这一块来提供一个IO,这就是我所表达的,因为代码耦合造成了整个系统的复杂度在扩散,底层改变得越多,整个系统的影响就会变得非常高。

 

第二是业务无关性问题。

10

当用cache层都无法降低数据库压力的时候,我们只能尝试对用户进行分库分表来进一步降低数据库的压力。分库分表之后,其实对于某些业务系统而言,对A是刚需,但是B和C并没有这种需求,但没办法,我必须要这么做。这就是业务无关性问题,即便是跟你无关,你也要做,因为代码耦合在一起。

 

第三点比较严重的问题就是业务相互影响

11

ABC三点都直接通过SQL语句来对数据库进行访问,从开发角度来说,不可能依赖每一个程序员对这三种语句都是OK的,假设他是一个没什么经验的开发人员,通过一个全表遍历的查询就能够直接把数据库干死,数据库一死,那无论多少个系统都会挂掉。

这就是单体应用架构的一些问题。

 

分析完之后我们就抛出单体架构之痛,主要体现在:

12

1、  研发成本高

为什么研发成本高?因为你的代码耦合,就意味着你要不断地去重复做很多无用的工作,迫于客户对时间的要求,只能不断地增加开发人员,导致研发成本变得越来越高。

 

2、  测试、部署成本高

单体架构意味着系统是在同一个进程里跑的,所以每一次大版本的升级都要对现有的系统进行重新的部署和测试,那测试和部署的成本也就相应变高。

 

3、  可伸缩性差

之所以是一个单体系统,也就是说系统可能是某一个非常小的部分受到并发压力,但是没办法,我要对整体的系统来均衡负载,并不能对某一个点来均衡负载,这是所谓的可伸缩性差。

 

4、  可靠性差

可靠性差刚才也提过了,可能会因为一个单点的需求导致我们整体的需求不可用。

 

其实业界对于单体系统并不是没有解决方案,而且解决方案很早就提出来了,就是SOA,面向服务的架构设计。面向服务的架构设计发生了非常本质的变化,把之前单体架构里关于user的操作提取出来,抽象出一个叫做user-service的层,来独立部署,在两个不同的进程去跑这样一个应用。

13

这么做的好处:

第一,  所有上层的业务线都只对user-service调用他简单的接口,那user-service基本就屏蔽了底层的复杂度,对于上层不需要了解复杂度,只需要调用接口就行了;

14

第二,  user-service只通过一个入口对db进行读写的操作,就可以安排经验非常丰富的程序员来写SQL语句;

15

第三,  举例来说,user-service这层受到并发压力的时候,不需要对整个单体系统进行扩容,只需要对user-service这一层进行扩容就OK了,这也是之前单体架构没有办法做到的。

16

 

那么,说了这么多好处,好像看起来单体应用的问题都已经解决了,但为什么在国内甚至整个业界,SOA在落地的最后一步都会卡住,问题出在哪呢?

 

据我所知,京东为了支撑618活动海量的吞吐量,线上的整个服务层是由15000个服务实例在支撑,在没有容器化技术出现之前,就意味着说,为了维护这套系统,必须有15000台虚拟机在工作才能把这套系统支撑起来,那么请问15000台虚拟机怎么用?没有办法用,或者说运维成本非常高。这也就是SOA迟迟卡在最后一步的非常重要的原因。

 

SOA的问题在哪里?

17

主要有两点:

SOA的优势在于,项目模块化而非服务模块化;

SOA本身缺乏多服务运维,导致运维复杂度扩散。

 

当架构运行到这一步的时候,整个业内都在呼唤一个新技术的到来,这个新技术就是以Docker为代表的新一代容器技术。

18

举一个不太恰当的例子来理解docker技术:

 

我们把数据中心理解为一个冷库,所有的业务系统都是冷库里的海鲜,制冷设备其实就是操作系统,windows或者linux。

 

以前,所有的海鲜都在同一个库房里,而每一种海鲜都需要有温度的独立控制,这种架构就显得非常不合适。

19

接下来就是虚拟化这一层,虚拟化倡导的是在整个数据机房里面通过钢筋混凝土的方式把库房隔成单间,单间里再独立部署一套温控设备,这是现在广泛应用的技术。

20

接下来docker做了什么呢,即为软隔离的技术,原来用钢筋混凝土做隔间,现在不用了,而是用一种新型的材料做隔断,每一个隔间里也不用再去部署独立的温控设备,而是铺上相应的管线就能达到目标。

21

随着docker的出现,使运维工作也上了一个台阶,接下来一个非常重要的东西就是kubernetes带来的容器编排引擎,kubernetes相当于整个制冷系统里的制冷机器人,它能够帮我们迅速在仓库里隔离不同的单间,而且这个状态是非常快的秒开级的速度。

具体到现实里,kubernetes能提供的技术有哪些呢?

22

第一就是灰度发布,所有线上的迭代基本上用户是完全感受不到的;

第二是自动伸缩,可以去设置更多的规则来完成;

第三是自动化运维

 

容器化微服务为高校信息化带来什么呢?

23

我的理解是,它原生继承了SOA所有优点,为SOA落地扫清了最后的障碍,为“高可用”奠定了技术基础

 

最后谈一下联奕在这块技术领域的尝试。

 

24

2015年,组建微服务+容器化团队,做完了技术选型;

26

2016年,提出“微服务·大智慧”战略口号,完成了核心系统的改造,召开产品发布会,发布基于微服务架构的完全学分制教务系统;

25

2017年,我们计划将全线产品都采用微服务和容器化技术来进行改造,希望通过联奕的努力为高校信息化在“高可用”方面贡献绵薄的力量。

27

不能单单只谈论“大而全”的概念,而更要踏踏实实地做好系统。

脚踏实地,方能仰望星空,这是联奕的态度。

 

  • 脚踏实地,方能仰望星空——从单体应用到微服务的进化之路已关闭评论
  • 589 views
    A+
发布日期:2017年02月24日  所属分类:技术探讨
双, 月