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

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

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

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

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

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

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

第一块内容，为什么我们要做微服务？

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

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

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

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

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

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

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

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

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

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

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

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

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

实现微服务的三大利器

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

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

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

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

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

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

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

gRPC的特点和功能

首先介绍一下gRPC。

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

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

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

选择Etcd3的原因

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

实际上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。 

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

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

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

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

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

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

实施微服务的要点

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

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

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

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

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

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

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

App后台的架构改造

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

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

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

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

事实上，真正的拆分是发生在API Gateway这个地方。

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

打造敏捷的开发团队

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

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

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

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

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

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

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

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

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

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

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

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