微服务落地践行渐进，4个Q&A一窥金融微服务现状

1月13日，中国双态运维用户大会在北京举办。来自银行、保险、证券、政府、央企等多个行业的330多位企业用户参加，其中工商银行信息科技部副总经理张艳，国泰君安信息技术部总经理俞枫、海关总署科技发展司运行安全处处长张芳、平安科技系统运营部总经理陈亚殊等分别发表了演讲。本文为数人云CEO王璞在双态运维用户大会DevOps、容器与微服务分论坛上的演讲实录。演讲结束，与在座金融客户展开了精彩的Q&A分享。

容器、微服务、DevOps三者，业内的共识是密不可分。没有微服务，DevOps落地不下去，没有容器，DevOps也无法真正实现敏捷运维、自动化运维。DevOps、容器、微服务为更好的构建PaaS提供了方法论和技术手段。

1
PaaS之承上启下

PaaS作为云计算的承上启下要素，向上支撑各环境应用，向下跟IaaS、计算环境、计算资源对接，是企业云化的必由之路。

PaaS三大技术趋势

1.应用容器化，容器正在成为云计算原生应用的标准交付方式。

2.微服务网格化，随着企业对微服务的认知越来越深入，下一代微服务着重把应用管理作为核心。因为企业应用一定要有很强的管理在微服务架构上，不能让应用去“裸奔”。数人云没有提微服务化，因为微服务化已经是不争的事实。应用微服务缺乏强大的管理，需要服务网格这样的下一代微服务技术。

3.行业生态化，PaaS技术本质上是支持应用的，应用跟业务紧密结合，所以PaaS最终是要和业务层面融合，行业需要生态化。

PaaS落地三大要素：

PaaS要在企业客户方面落地不可或缺三要素:规模化、统一化、标准化。企业客户落地云计算平台、技术，本质上是希望提高效率，对业务有更好的敏捷支撑。

所有应用，比如容器应用、微服务应用，都实现标准化。标准化以后进行统一化管理，包括部署、发布、故障恢复、监控告警等都实现统一化管理。最后实现模块化，整个系统都是轻量的，微小模块化的。只有基于这三点的PaaS平台和云计算平台，才能够让IT系统真正实现敏捷轻量，提高IT对业务支撑的效果。

2、企业IT架构转型之开发&运维

企业客户目前在架构转型应用中面临的现状是，企业里大量传统应用，客户希望先实现轻量的单体架构，即摆脱很多中间件，摆脱外部服务，MVC架构、单体复杂架构等首先实现轻量化。

数人云日常接触的客户中，走的比较靠前的客户已经在用Spring Cloud、Dubbo等架构，部分客户相当数量的应用已经微服务化，不过处于中间状态，正在考虑评估微服务架构的客户比例还是最大。总之，企业目前的现状是为服务应用、轻量单体应用，以及传统的巨石应用并存。

在架构转型过程中，正确和常态的路径一定是一步步走过来，而不是传统架构丢掉直接上微服务。

DevOps和容器@轻量单体

应体应用架构下，DevOps、容器帮助企业实现敏捷IT。首先，持续集成持续交付CI/CD，只要应用是相对轻量的，就能加快中间件应用。CI/CD其中重要的一点是变更发布管理。

数人云某客户上了容器的应用都是轻量化的，基于 Tomcat 和微服务的应用。当基于容器实现快速发布以后，企业发现，所有发布里有一半的发布失败是由于配置不正确引起的。所以，如果没有发布变更管理，发布失败的中间环节有方方面面的因素。

当基于容器实现快速发布之后，容器对环境的异构做了一层屏蔽，这时如果出现处理的问题就是配置管理的问题了，由于涉及不同的环境和应用，配置环境变成应用发布很容易出错的环节。

DevOps和容器@微服务应用架构

数人云做了企业客户微服务落地状况的调研，在报告中，有15%左右的企业引入了Spring Cloud、Dubbo。微服务在企业里首当其冲的是敏捷开发，因为微服务是一种切实的敏捷开发的方法。

敏捷开发在IT界已经推广多年，但很多时候敏捷开发推的都是方法论，比如Scrum。微服务是一套切实能够落地到IT人员、开发人员开发过程中的实践方法，这是微服务首当其冲的好处，很多企业的开发部门对微服务非常欢迎。不过，15%还是偏小的一个采用比例，微服务还不是企业客户主流的IT架构。

开发人员都比较欢迎微服务，因为能够提升开发效率，落地敏捷开发，但微服务的阻碍还是不小的，微服务对开发运维来说，带来的复杂度急剧上升。传统运维管理的服务器数量、应用数量有限。企业决定采用微服务本身就表明业务很复杂，单体应用做传统的瀑布式开发效率太低，微服务将应用拆分成较小的模块，因此微服务应用一旦上线，程序的数量呈现爆炸式增长。

例如，数人云某个传统企业的客户，目前部署了微服务相关的应用，基于Spring Cloud、Spring Boot，跑在几千个容器上，几千个容器如果通过传统运维方式去管理的话几乎是不可能的。这就是很多微服务无法落地的原因——很多企业客户缺乏相应的运维能力，没有相应的平台、工具、方式、方法管理微服务应用。

微服务落地的必要条件

微服务应用落地，首当其冲是配套工具链的完善。开发人员采用微服务的影响相对改变小一些。采用SpringCloud或者Dubbo、gRPC等，只是开发框架上的并更。其他开发流程如代码托管、代码审查、测试等并不涉及，所以开发流程相对简单。但微服务对运维功能的要求就会复杂，相应的快速配置能力、完备的监控能力、快速部署能力等对传统运维来说都是缺失的，容器能够补足这方面的能力，让运维部门具有DevOps的能力。

关于微服务的拆分，其实是业务部门需要真正解决的问题。微服务对组织上也有变更，将团队化整为零。通常每个单独的微服务程序都由7-10人的小团队来负责维护，这些都是微服务落地的必要条件。

对于数人云来说，直接能够给客户提供的帮助，首先是工具链方面，数人云产品层面具备丰富的微服务配套工具链，从监控、日志、调度、故障自动化修复等等都有完备的工具链。在落地方法上，数人云搭建了自己的生态圈，和很多合作伙伴合作，例如跟埃森哲公司在合作，帮助企业客户落地微服务，进行业务的梳理。

容器和微服务共生

容器技术补齐了微服务相关的工具链，对企业全面向云计算转型提供了很大帮助。应用架构是微服务分布式的，相应的运维也要有自动化、敏捷运维的能力。微服务跑在容器上才能发挥它最好的特性。容器是目前最流行的应用环境，基于容器的微服务部署和更新更快，更轻量，服务之间的调用、服务发现、负载均衡等更灵活。

不过，微服务不是万能的。简单的业务场景单体应用其实足够，微服务一定是应用在复杂的业务场景下，只有复杂的业务场景才有很大的维护成本、维护压力，微服务是用来降低复杂业务场景的维护成本。

基于容器云的微服务运行时管理体系

一个完整的微服务管理体系，除了开发框架之外，对运维部门来说，运维微服务应用最基本的路由、负载均衡等功能，容器可以提供，不过容器提供的只是一部分跟微服务相关的能力和工具链。周围还有一大批需要配套的工具，比如配置管理、API网关、注册发现、应用监控等等。这里的监控不是容器CPU内存的监控，而是业务逻辑的监控，更准确一点是全链路跟踪的全链路监控。容器满足了微服务运行时管理的需求，不过周边许多权限、网关、配置等尚无余力满足。

统一配置中心是微服务体系的核心

统一配置管理，是微服务落地时很核心的点。要在平台工具上落地微服务首先要具备快速配置能力，因为客户采用微服务和容器平台以后，很快会发现50%以上的发布失败是因为配置没搞对，因此配置管理是微服务里首当其冲的问题。

因为每个企业客户都有开发环境、测试环境、生产环境等很多环境，同一个应用不同版本在不同环境下的配置不同。几何级数的配置项、配置元素的增长会导致配置管理的复杂度急剧上升，需要统一的配置中心进行管理。数人云在帮助企业客户落地微服务时，首先会做的是把配置搞定，没有灵活快速的配置管理能力，微服务运行不起来。

变更发布管理（灰度发布 v.s. 蓝绿部署）

在发布管理方面，数人云帮助企业落地的发布管理主要是蓝绿部署，因为很多企业的应用本身不支持灰度发布。蓝绿部署也是切切实实的快速发布，发布用变更窗口的方式来实现。

例如，周五晚上12点起进行发布变更，12点就要停服务中心。蓝绿部署可以显著地缩短服务不可用的变更窗口。怎么做呢？客户在线上有两个版本，蓝版本和绿版本。现在负载均衡器将流量指向对外提供服务的绿版本，蓝版本作为备用的方案。同时，新程序往蓝版本上部署推送，更新时只需要把流量切换到蓝版本。发布流程最后简化为只需要进行流量的切换。流量可以快速切换，中间的窗口期只有短短几分钟，如果流量切换过来一切正常发布即完成，如果流量切换过来发现问题，可以再将流量切回去。这样开发人员、运维人员不必当场熬夜去修复，极大地减轻了发布的压力。

传统发布方式下，每次变更窗口有好几个应用排队发布，一个应用发布完成后才可以发布下一个应用，一旦中间某一个应用发布失败现场修复的压力非常大，短短的发布窗口需要几个小时内完成抢修，非常不可控，团队经常需要晚上熬夜排队。而结果往往等了半天，前面的应用没发布成功，后面的还得继续排队等。

3金融行业之践行渐进

数人云在金融、能源、制造、快消、政企等行业的基础上，继续深耕强监管、强安全，高复杂度的金融行业。以某商业银行为例，数人云帮助落地了大规模微服务容器平台。该商业银行近年来互联网业务发展迅猛，原有系统架构无法支撑其未来规划。2016年6月开始全面实施应用微服务化，已实现蓝绿发布。

首先，营销系统全部是轻量化的应用，基于Spring Boot、Tomcat、SpringCloud等，跑在容器平台上。该银行对外营销频次非常高，通过线上微信公众号、手机APP、线上门户、合作伙伴等渠道，每月对外营销达上百场。

每次营销活动或多或少都对IT系统有变更，哪怕是配置变更，因此每次营销活动对IT系统都是一次不小的挑战。发布的时候仅仅靠容器是不够的，需要实现模板的批量发布。每次发布看起来只是一个个的容器程序，实则不然，其实是一组组一批批的容器，只有帮客户做到批量的应用发布，才能显著提升发布效率。

蓝绿部署方面，该银行密集的线上营销中，每一天会有一个重点营销活动，那么营销活动的流量如何分到特别的人群、区域？在后台应用的上千个实例中，并不是每一个实例都分配同等的流量，要通过流量分发，做线上流量控制。数人云借鉴Google做灰度发布的方式为客户提供图形化的流量控制，这和微服务实施后的限流分流是息息相关的。

另外，该银行客户的数据流量非常大，对日志收集带来非常大的的压力。数人云建议客户将应用程序的日志全部交给Kafka采集，Kafka可以做到很大数据流量的分布式消息应用。

分布式数据传输分布式消息应用很难保证每一个消息都可靠地传递。Kafka有两种模式：一种保证消息传递至少一次，但也可能多次，对很大的日志量来说偶尔丢一两条可以忽略不计。Kafka的并发量很大，可能带来偶尔很小的数据量丢失，也可能带来日志的乱序，这在分布式系统下都是可以容忍的，“鱼和熊掌不可兼得”。

关于快速建立支撑微服务体系，数人云有几点总结：

1.开发框架不能用重量级的应用体系，要么是轻量化单体架构的Tomcat等，要么采用Spring Cloud等微服务架构。2.要有微服务平台，具备快速配置管理能力、部署能力、监控能力、应用管理能力等配套管理能力。很多企业的痛点是，开发人员快速学习微服务开发技术，基于Spring Cloud做业务系统后，业务系统无法上线，因为运维部门缺乏配套的工具、平台支撑微服务线上运行管理。3.DevOps融合，平台管理需要把链条全打通，实现快速发布、快速上线、自动修复等。容器经过几年的普及企业已经相对了解，但容器本身是纯技术平台，基于容器、DevOps的落地还有很长的路要走。

数人云微服务On PaaS 产品体系

数人云现在的重点是微服务、轻量单体应用。以前数人云帮企业客户落地重应用的容器平台，但后来发现价值不大，反而对企业来说，除了维护重的应用外还需要维护容器，容器平台并不能实现自动化运维。经过几年的实践和摸索，数人云跟企业客户达成的共识是，传统应用不经过改造无法上到云PaaS平台。

轻量架构下的应用如何基于PaaS平台支撑？以敏捷开发为例，企业客户通常选择 Spring Cloud、gRPC 等主流的开发框架，然后在微服务工具链层面配置监控、报警、部署、快速发布等方方面面的能力，最下面承载的则是容器平台。

数人云现在还可以帮助客户落地服务网格化技术。它能够进行异构架构的兼容，gRPC就是服务网格的一部分，Google推的 Istio，Linkerd的Kubernetes 都支持 gRPC，gRPC成为通讯协议的一部分。基于通讯协议相应周边的管理，在服务网格这一层可以做灰度发布、A/B测试、流量控制、高级熔断、加密、白/黑名单机制、权限访问控制等等。

服务网格被称作下一代的微服务，因为用了服务网格以后，所有微服务管理的诉求都自动化地满足了。80%-90%的应用管理需求都在服务网格里自动涵盖。这对开发人员来讲，微服务开发的门槛急剧降低，不需要考虑未来应用上线时流量控制、灰度发布等等，只需要考虑业务。数人云微服务On PaaS 目的就是帮助企业客户降低微服务架构、上云转型的门槛。

Q&A

Q1：感觉对DevOps的理解不太到位，能不能具体地讲一下？

A1：DevOps准确来讲，现在业内还没有统一的认识。互联网公司的DevOps目前是比较统一的，比如Goolge，但是互联网公司的DevOps，我个人理解没办法在企业直接落地。

在Google，程序员不止要负责应用的开发，还要负责相应的测试，单元测试、集成测试等等。另外，应用的部署、发布、上线也是开发人员自己做。所以互联网公司讲DevOps，更多讲的是开发运维的融合。我之前在Google时，不仅要做代码开发，也要把测试的代码全写出来。

Google有一个理念，开发人员每写一行业务代码，测试代码要写十行。然后，开发人员利用各种发布平台定期发布，比如每周做发布，在Google 运维的人员叫“SRE”。SRE部门准备好各种平台，开发人员可以用这些平台做发布、监控、日志管理等工作。

Google目前有三万名左右的IT人员，其中SRE的运维人员只有一千多，比例很低。所以在Google运维人员不可能帮每一个开发人员或者业务部门做上线。像传统IT开发人员提工单给运维，在Google是不可能的。Google这种做法，它让开发做更多的事情，运维人员很少，只是负责维护平台。所以，Google一千多人管理着几百万台服务器，平均每人管两千台。

但传统企业目前不是这样，传统企业开发和运维之间壁垒比较大。数人云帮助客户落地DevOps 时，基于的理念是，不要破坏现有开发的流程。DevOps应该是开发和运维深度融合才能做到的。讲DevOps，首先要讲理念、组织的变革，但是要想把文化变革、组织变革打破要很长时间。

从落地的角度，DevOps更多落地在运维部门，很具象的工作就是，帮助运维部门去实现DevOps的能力，比如快速部署、快速上线，应用的快速配置，自动化管理能力、故障的自动化处理等等。把以前的运维工作尽可能的自动化，提高效率，这是狭义的DevOps理念，也是我们现在接触到的。数人云不会帮客户落地像互联网公司那样的DevOps，开发做很多事情，运维可做的很少，并不是这样的。

Q2：微服务适合复杂的场景，那么一个简单的促销是不是适合？微服务有多“微”呢？微服务和ESB 服务相比，有什么差别？

A2：第一个促销场景，促销场景本身有些条件，促销很重要一点就是必须特别频繁，促销内容在平台要发生变化。比如，今天的促销内容和明天的不太一样，或者这周的促销和下周的不太一样，业务平台需要频繁变更，这时候微服务是适合的。

因为微服务是一种敏捷开发的落地实践方法，只要业务频繁变更，对开发的要求就必须敏捷开发，快速实现。所以，只要业务场景在不停地快速变化，促销又是互联网线上的方式，肯定是适合的。

关于复杂性，如果业务逻辑简单，逻辑变化少，并不适合微服务。比如数人云和很多银行客户合作，银行核心系统很复杂，但是银行系统并不是需求频繁变化的场景。很多银行在做“瘦核心系统”，就是银行核心系统的功能越来越单一，越来越瘦，并不是把复杂的周边的业务也放到银行核心系统里。银行核心系统虽然复杂，但业务不会频繁变化，也不一定要上到微服务场景下。复杂的业务系统，业务需求又不停变化，这种场景适合微服务。

第二个问题是和ESB 比，服务网格和 ESB 有很多相像的地方。ESB有业务逻辑串起来，很多不同的业务系统都上到ESB，互相的权限通过ESB打通。从功能角度讲，ESB和服务网格之间很相像，不同点在于ESB是传统架构下的，并没有考虑频繁迭代、流量集中爆发等问题。

但是微服务情况下，整个之间的互相请求、依赖、通讯等等都会进行统一的管理，这种情况下也很像ESB把不同业务之间的流量进行统一管理，但是服务网格更看重的是面向大规模的控制，那流量突发怎么做限流，或者突然故障怎么做熔断等等。最本质的问题是类似的，但是具体的问题表象和需求不同。

Q3：在实际部署过程中，PaaS平台在底层资源的调用一定要用分布式云架构，传统主机是否可以？两者在最后效果上有没有什么异同？

A3：数人云当初两种情况都有，有些场景比如业务量比较大，企业客户为了减少复杂度，容器PaaS平台直接落地到物理服务器上。还有客户为了方便管理，把PaaS落地到IaaS上，两种情况都有。

这其中的考虑是，首先业务量大如果再引入虚拟化这一层会引来额外的复杂度，此时用物理服务器更好。其次，客户有很大规模的物理服务器，直接在上面部署PaaS，在物理服务器上去调用。

第三种，资源动态的调整或资源频繁调配，这个场景很常见，需要IaaS。比如银行客户，内部业务系统分不同的域，不同域的业务复杂性随时间变化经常会发生变化，需要不停地做资源动态的调整。如果用物理机太麻烦，企业客户会选择下面有一层IaaS来做。

基于PaaS也能做一部分的资源动态调配，但是调配维度不同。数人云帮客户落地PaaS时会做资源的整合。从划分的维度，PaaS平台是按照应用程序来划分，IaaS的资源划分是按照业务系统。

Q4：微服务重新开发，最佳的开发框架或者实践有什么可以分享的？第二，旧有的系统改造到微服务这块有没有什么经验？第三，DevOps以前也有很多像敏捷开发的方法论，它们之间有没有什么关系？

A4：首先第一个问题，微服务的开发框架。企业客户在做选择时都希望降低风险，选最主流的框架，现在看最主流的开发框架就是Spring cloud，这也是业界的自然选择结果。其他语言也都有些微服务开发，但是用的人少一些。如果是Java应用，目前比较好的选择是Spring Cloud，也有很多客户用了Dubbo，其他架构都是偏小众的架构，主要还是看客户自己的需求。

第二个问题，传统业务要转到微服务架构上，一定要循序渐进。比如Java应用，首先Java中间件的应用，先脱掉，不要再基于这么重的Java中间件。目前相对流行的是Spring Boot这套逻辑。

有了轻量的单体化应用之后（基于Tomcat），往后走基于微服务的框架，上到Spring Boot，再上到Spring Cloud，这是比较平滑的方式。Spring Boot 在很企业客户中用的非常多，是很方便的一套单体开发架构。

企业客户目前的现状是老的应用很多，不会一次就改造完，传统的应用可以先选择一部分容易转的转到轻量单体架构上，然后再转到微服务框架上。目前企业客户是轻量的单体架构、微服务架构，以及大量传统的架构应用并存。老的架构应用目前上不到PaaS平台，只有轻量的单体化加微服务应用才能上到PaaS平台。

现在业内的共识是，微服务、容器、DevOps这三者是密不可分的。微服务更多是针对开发人员，是一种真正落地的云开发方法。很多企业客户也讲敏捷开发，派团队成员学习敏捷开发的方法论，但是敏捷开发仍然无法在企业当中落地。

这是因为，只学会了方法，但没办法落地到具体的编程，即开发环节上去，自然没办法做到敏捷开发。很多开发者回来写的程序依然是J2EE。J2EE 编程的理念和方法并不是敏捷开发的，是偏向于瀑布式的。

微服务是具体的开发环节上的敏捷开发方法，开发能力化整为零，每个团队做简单、具象、单一的逻辑。微服务首先是一个具像的敏捷开发方法，实践方法。

微服务在落地时，比如程序运行时，复杂度很高，因为不是一个程序，是一批程序一起运行，对运维的管理就比较复杂，这时候可以利用容器实现微服务应用的自动化管理。微服务一般都会上到容器，因为微服务应用不再是单体的部署方式，不再是部署到Java中间件上。基于微服务架构，几百个进程进来，用容器的方式实现快速部署动态调度，微服务部署到容器上，实现基础的轻量化运维。

轻量化运维，快速部署、自动化调度，逐步往DevOps方向走。DevOps更多强调自动化的运维能力，提高运维的效率，快速部署，出了问题自动化修复。需要用到工具和平台，这就是数人云现在帮客户去做的。

把微服务业务在运行时缺失的管理方式方法、工具平台，工具链补齐。首先是配置管理能力、完备的监控能力等等，普及之后运维人员就有能力来管微服务应用。这其实是DevOps里面最狭义的，让运维的能力变得轻量。

如果要真正实现DevOps，就像目前一些互联网公司做到的，开发和运维真正的深度融合在一起。企业目前的运维一般不具有编程能力，所以真正的DevOps还需要很长时间去落地。