2016 年 8 月 13 日,又拍云 Open Talk NO.24 在广州落幕,本次 Open Talk 的主题是“ Docker 与微服务的架构实践”,PPmoney 敖小剑在活动中分享了《PPmoney 微服务之路》,以下是敖小剑的分享全文:

除了技术内容的分享,敖小剑也提炼了很多在实现微服务过程中团队、管理方面的经验,全文较长,特将这些观点放在文前:

  • 当你推进微服务框架的时候,不是简单的推进微服务框架,而是推翻整个公司的开发流程。
  • 微服务架构真正成功之处,是在于拥抱一个小型、跨智能团队,鼓励扁平、自我管理的组织。
  • 微服务团队应该按照业务而不是按照技术来划分组织。
  • 先把自身打造好,然后再孵化满足要求的新型业务开发团队。
  • 资金、技术、专家,缺一不可。
  • 放弃项目思维,引入产品思维。

以下是敖小剑的分享全文。

今天我给大家讲的内容是PPmoney的微服务之路,简单介绍一下,我负责的基础架构,有些公司可能有类似的部门。今天的内容大概是这样的四个点:

  • 首先,我介绍一下为什么要上微服务框架;
  • 其次,讲一下微服务框架的一些具体做法;
  • 第三,我会给大家介绍一下在整个微服务生态当中,除了微服务框架之外的支撑体系;
  • 第四部分,我会给大家介绍一下如何进行旧有系统的迁移改造,以及有同学感兴趣的开源计划。

image.png

用微服务解决快速发展中的技术债务

第一块内容,为什么我们要做微服务?

先简单介绍一下我们公司——PPmoney万惠,我们在整个IT行业名气不是很大,是万惠金科旗下的全资子公司,专注于互联网金融行业的服务和安全。从创业到现在,4年时间,累计成交额超600亿元。

这是从零开始的4年,对一家公司来说,是一个非常早期的阶段,即使在互联网金融发展的阶段,一家公司能在4年时间达到600亿元的级别,大家可以想象一下发展之迅猛。4年做到600亿元,为什么我会强调这个东西?这里面可以看到野蛮生长这个词,对互联网金融企业来讲,做不到这一点的基本上都是死掉了,做到这一点之后,就成为了一家大家熟悉的初创型企业。

大多数创业公司在初期是很郁闷的,没有足够的技术,所以早期时,遵循什么样的原则?造成技术栈多样化的原因又是什么呢?

首先是“黑猫白猫,能上线就是好猫”,只要能把代码写出来、能上线,就OK;第二个是怎么快怎么来,包括买。买是更快的,我们早期有很多的代码也是买过来的。

那到了这两步之后,有些问题就出现了,规划不足、实施艰难;需求太多,来不及规则;变更太快,规划跟不上;到了后面还有人员变动频繁。整个野蛮生长的过程中,成本会越来越高,技术债务会越来越多,在现有需求上如果想加一个新的功能,也会变得比你想象中的要难得多。这是目前整体的情况,而且重要的是出现了“恶性循环”。

image.png
有没有人发现这里面有一个很要命的事情——大家都太匆忙,太急了。这会出现几个问题:

  • 方法不得当,开发效率非常低,
  • 问题积累,工程师不堪重负
  • 没有时间改进,咬牙硬扛:即使你告诉工程师要改进,他也会告诉你说,我们没有时间。大家都很忙,大家都很无助。

我们的改变大概是这样子:

image.png
首先事情要规范化,让无序的开发变成有序。无序的开发是什么概念?逮到哪就做到哪,至于用什么技术:有什么人用什么,会什么用什么。有序的开发有很重要的事情,叫做“统一”,同时简化技术栈。

第二个就是要“可重用”。之前的项目都是从头开始或者是从上一个项目里头copy过来,这里面是有很多事情没有做好的:基础类库、基础设施、基础架构。做这些j目标是提升大家的起点,而我们经常说的一句话就是说不要输在起跑线上。

第三个是“敏捷”。应该所有的同学都懂敏捷,但实际上这个东西对我们而言做得非常不好,现在基本上是属于0的状态,各个团队都在宣称敏捷,但是实际做的不太好。

第四个就是“自动化”。这个就是我们希望所能改进的一个地方,自动化概念比较多,包括自动化测试、自动化部署、云技术、容器化等,解决这个问题的目标:摆脱低级重复。

这一整套四个大方案,是我们希望解决前面问题的一些出发点和做法。DevOps和每日发布是我们的目标。第一部分大概就是在这里,就是我们处于什么状态,为什么要上微服务。

实现微服务的三大利器

如何实现微服务?这个部分相对来说比较有意思一点。

首先,我给大家介绍一下Dolphin微服务框架,我相信应该没有人知道Dolphin微服务框架,这是我们3月份刚开始自己动工搭建的一个微服务框架。

今天主持的女同学之前曾经问我,为什么你们的服务化框架要叫做Dolphin。当时我给了一个很官方的解释,我说我们希望这个框架做的很敏捷、很轻快、很优雅,就像海豚一样。那位女同学很感动,说你们做开发的同学都这么浪漫,取这么好听的名字,就好像是自己的孩子。其实,Dolphin这个单词是我女儿的小名,海豚,我出于私心将这个框架以我女儿的名字命名了,这也代表我个人对这个框架的期望和决心。

image.png

我们的愿景——要打造业界一流的微服务框架。Dolphin要打通整个业务的全流程,这个可能是跟其他微服务框架特别大的不同,这也是造成我们技术选型的一个重要的基石。

通常来说,大家的微服务框架,通常是指服务器到服务器,不同的的服务器之间调,但是这个地方我们会有一个非常重要的选择,我们必须要把App覆盖到,因为这个需求技术选型可能会变得特殊。为什么要加这个需求?因为我们公司目前80%成交额来自于App。因此我们除了考虑服务器端之外,要考虑从App到服务器端的数据通讯,我们希望它能覆盖日常的开发场景,包括手机App开发、Web服务器开发、应用服务。另外要实现的一个目标就是要三位一体,也就是下面这句话,“打通开发、测试、运维三条线”,实现整个流程的畅通,实现全程自动化。将整个流程所涉及到的所有环节都实现自动化,这是Dolphin的整体目标。

image.png
我们看一下Dolphin的技术栈。我相信这里头除了SpringBoot之外,剩下的大家应该接触的比较少,因为太新。

  • Google开源的gRPC框架,优点是支持多平台多语言,支持手机App。
  • SpringBoot,这应该是Spring团队集大成之做,口碑非常好,重要的是它非常好用,而且比较容易上手。
  • Etcd3,这个东西真的鲜出炉的,离现在可能就40多天,用于服务发现和配置,这个是主要的技术栈。

gRPC的特点和功能

首先介绍一下gRPC。

image.png

这个Protocol Buffer3.0版本是比较新的一个版本。gPRC一个重要的地方就是HTTP/2 协议,不算是特别的新,但是大家真正用的比较少。HTTP/2是一个新的技术,很重要的一个事情是多路复用。同时Server Push能够让服务器将响应主动“推送”到客户端。Server push这个功能,非常非常有用,由于时间原因不再展开。

真正对我们来说重要的是对Android/iOS的支持,这对我们来说是杀手锏级的特性。

gRPC的主要特性有哪些呢?首先它可以有效提高网络利用,其次就是高效编解码机制、灵活的编程API。重要的是它支持stream

image.png
选择Etcd3的原因

我们做技术选型的时候,在Etcd和Consul之间做了很多的权衡。7月份之后,我们做了一个重大决定,准备把Consul换掉。因为我们发现了一个更适合 Dolphin的东西——Etcd3。我说的是更适合,不是说更好,两个都很好,我觉得你怎么选择都是对的,但是对于Dolphin框架而言,我们会选择Etcd3。

image.png

实际上Dolphin做到0.1、0.2到0.5,一直用的都是Consul,近期我们决定把它换过来,因为Etcd3给了我们一个很大的惊喜,它的通讯机制改了,Etcd3改用gRPC作为通讯机制,替代原有的rest。

除了速度快之外,它重要的就是有一个特别实用的功能,就是用流做服务器端推送。这是什么东西?现在业界常用的就是Long Pull,这是什么概念,比如服务器端hold住请求5秒钟,如果5秒钟之内有更新服务器端就给出应答。每5秒钟客户端要来这么一次,来保证服务器随时有机会发请求给你,这就是常见的Long pull。

Etcd3用Stream Api做变更通知,TTL和健康检查也是基于Stream。这样对我们的服务发现是非常重要。为了让服务器的变更及时通知到客户端,就必须主动推送让客户端及时得到通知,用传统的Long Pull就会很痛苦。而Etcd3当中,为了改进这个东西采用了gRPC。

我们当时做完了服务注册、服务发现,当时服务量不会特别大。然后我们要做配置中心,大家可以想象一下通常配置数量跟服务数量,通常不是一个级别,这个时候如果你要关注哪个配置项的更新,你想想你要开多少个客户端去做Long Pull。后来我们就觉得还是自己玩吧,自己写一个gRPC服务器端,用gRPC的流来来告诉客户端配置项修改了。考量之后,就发现Etcd3了,它的做法正好和我们的想法一致。

Etcd3现在你们不要用?为什么?因为官方的版本的java client还没有。我要用它,找了他们的架构师,他说还没有开始开发,如果你们急着用的话,就开始做。所以这个大家先不要用Etcd3,先等等。

微服务依赖的基础设置和通用服务

接下来,给大家介绍一下微服务。

把框架做好之后,是不是就这么简单的可以把一个微服务在一家公司里推行出来?我遗憾地告诉大家,这个没有什么必然的关系,并不是你有了微服务的框架,就可以把后面的事情做好。

大多数的技术人员,指望微服务单枪匹马的解决问题,“只要微服务一出来,我就轻轻松松搞定。”但是想象一下,你一个人英勇地出现在敌人面前,下场只能是Game Over。 

image.png
实际上,在整个过程中,会有一系列的东西需要去为它服务。

如果微服务作为一个核心,通常有一个标配的东西,服务中心,这个应该是任何一家做过服务框架的公司都会有的,名字可能不太一样。这个服务中心可以看服务状态、做管理,以及设置各种服务的路由、限流。常见的还有配置中心,还有应用性能监控,这个大家可能接触的比较少一点。

另外还有一些资源中心,配置系统资源或者是监控资源使用,然后另外就是日志管理,基本上这些算是标配。

image.png
在这个基础上,更进一步,将一些通用的功能做成服务。

前面那些功能是标配的,那这些不太一样,它是以一些通用服务的方式来做功能,比如说有一些加密服务、信息收集服务、鉴权服务、限流服务,还有一个就是业务平台,它不是业务的一部分,但是是必不可少的,统一的短信服务、验证码服务等。实际上,这些东西也算是一个系统当中必不可少的,尤其是前面的这两块,那在这里面有一些功能是内置在框架里头的,像加密的支持。加密是跑不掉的,如果你去一家公司是搞金融的,你放了几万块钱,没有加密,你有信心吗?

Docker,现在我们还没有做,不是我们不想做,是没空,我们还不太会,现在还在摸索阶段。

实施微服务的要点

在整个实施的过程中,真正的要把微服务做好,是有很有考量的。很多是不知不觉之间决定成败的。

比方说敏捷开发。敏捷开发这个是必备的,如果是敏捷都没有做到,微服务真的是“连爬都还不会就想跑”。有时候微服务一上手发现不合适了,做这个东西之前先自问一下,你的敏捷开发是不是跑起来了,你的团队是不是用敏捷的方式做开发。

在座有架构师吗?如果是做过架构,规划一个框架或者是路线的时候,你的组织架构是不是跟你的框架匹配。组织决定架构,为了实现服务化,你必须要让你的组织结构做出相应的调整。需要组建跨功能的团队,这个团队一定不是单纯的只有开发、只有测试、只有运维,或者是只有产品,这些功能应该都在你的团队里头,重要的是要减少部门墙带来的沟通成本。这个墙是非常可怕的一件事情,它可以让一个小时能做的东西,一个星期都做不完。

建议微服务团队按照业务而不是按照技术来划分组织,必须要想办法在一个团队内全栈,让团队自治。这个是我们现在试图想做的,但坦白说这个事情很难。

第三,这需要有产品的思维,一定是产品,一定不要是项目。产品跟项目有不同?项目是做完就团队解散,各找各妈!产品是什么概念?这个产品是你的,你要上线。这是一个责任感的事情,做产品你要吃自己的狗粮,这个是非常重要的事情。

第四个是团队,你得打造一支能满足高要求的团队,这个要求是比较高,设计、开发 、测试都要搞得定,可能是三五个人,甚至七八个人,要一个团队啃下产品线,包括前端、后端、测试、运维。

对大多数公司来说,这四个要点完全做到还是挺难的。你前面硬的东西得有。如果你没有足够的支撑,这是一个很悲哀的事情。如果你真的要去推一个微服务,你在拥有一个微服务框架之外,你要有一系列的生态体系和一系列的软实力的支撑。

image.png
App后台的架构改造

谈一下我们如何改造App架构和团队去更好地应用微服务。

这是我们原有的一个简单架构。

image.png
现在理财App带来了80%的收入,App后台架构一目了然,底层有一个SOA框架,但是要命是整个App的后台,所有代码都在一个WAR中。

这是我们期望的改造的方式。我们把这些war里面的东西拆成若干个服务,拆成服务之后,会有各自的数据库和缓存。

image.png
事实上,真正的拆分是发生在API Gateway这个地方。

image.png

拆到这一步之后,再下一步,把原来的SOA合进来,然后变成一个一个的完整的微服务。这才是App的后台的标准框架。

打造敏捷的开发团队

再谈一谈将架构部门打造为高素质的敏捷团队。

把架构部门打造成高素质的敏捷团队,这个是必须的,这个如果做不到,后面没得玩。

然后再孵化满足要求的新型业务开发团队。这个地方有一个很逗的词,孵化。为什么是孵化呢?因为很多时候情况下,即使你做到了第一步,你也仅仅是有一支架构部门的团队,而且也不可能满足整个公司业务各个产品线的需要的,你还要把整个的业务线的开发团队提升上来。

如何做到这一点很重要,你要想办法自己去培养、改造这样的团队,那这个时候这个词叫“孵化”,就是带领一支一支的团队,跟他一起去做业务改造,就像孵小鸡一样。

资金、技术、专家,缺一不可

计划一开始都是很美好,但微服务真正的难点在哪里呢?

今年,习总书记访问英国的时候,英国BBC记者问“英企能否在中国投资建设核电站”,中国驻英大使刘晓明反问:你们有资金吗?你们有技术吗?你们有专家吗?

我们为什么要提这个话呢?因为一个公司要真正的提升上去,你也要问一下自己有没有这三个要素。

第一个是资金,你要组建团队,要在整个公司推广,把所有的流程都走通,投入巨大;第二个是技术。第三个是专家,一般业务团队只有一个专家,能找到两三个就特别不容易了。

再一个就是变革,当你提微服务框架的时候,你不是简单的提一个微服务框架,实际上是推翻整个公司的开发流程。微服务是真正颠覆性的东西

你要推行一个微服务框架的时候,要把这些东西通通跑通,而且做顺、做好,你的微服务框架才能真正落到实处。如果有一个卡住你,你就会发现走的时候就感觉是瘸了腿的感觉。

微服务架构真正成功之处是在于拥抱一个小型、跨智能团队,而且它是鼓励扁平、自我管理的组织。这点是很重要。