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和容器@微服务应用架构
数人云做了企业客户微服务落地状况的调研（微服务2017年度报告出炉：4大客户画像，15%传统企业已领跑），在报告中，有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，开发做很多事情，运维可做的很少，并不是这样的。
Q&A
Q2：微服务适合复杂的场景，那么一个简单的促销是不是适合？微服务有多“微”呢？微服务和ESB 服务相比，有什么差别？
A2：第一个促销场景，促销场景本身有些条件，促销很重要一点就是必须特别频繁，促销内容在平台要发生变化。比如，今天的促销内容和明天的不太一样，或者这周的促销和下周的不太一样，业务平台需要频繁变更，这时候微服务是适合的。
因为微服务是一种敏捷开发的落地实践方法，只要业务频繁变更，对开发的要求就必须敏捷开发，快速实现。所以，只要业务场景在不停地快速变化，促销又是互联网线上的方式，肯定是适合的。
关于复杂性，如果业务逻辑简单，逻辑变化少，并不适合微服务。比如数人云和很多银行客户合作，银行核心系统很复杂，但是银行系统并不是需求频繁变化的场景。很多银行在做“瘦核心系统”，就是银行核心系统的功能越来越单一，越来越瘦，并不是把复杂的周边的业务也放到银行核心系统里。银行核心系统虽然复杂，但业务不会频繁变化，也不一定要上到微服务场景下。复杂的业务系统，业务需求又不停变化，这种场景适合微服务。
第二个问题是和ESB 比，服务网格和 ESB 有很多相像的地方。ESB有业务逻辑串起来，很多不同的业务系统都上到ESB，互相的权限通过ESB打通。从功能角度讲，ESB和服务网格之间很相像，不同点在于ESB是传统架构下的，并没有考虑频繁迭代、流量集中爆发等问题。
但是微服务情况下，整个之间的互相请求、依赖、通讯等等都会进行统一的管理，这种情况下也很像ESB把不同业务之间的流量进行统一管理，但是服务网格更看重的是面向大规模的控制，那流量突发怎么做限流，或者突然故障怎么做熔断等等。最本质的问题是类似的，但是具体的问题表象和需求不同。 Q&A
Q3：在实际部署过程中，PaaS平台在底层资源的调用一定要用分布式云架构，传统主机是否可以？两者在最后效果上有没有什么异同？
A3：数人云当初两种情况都有，有些场景比如业务量比较大，企业客户为了减少复杂度，容器PaaS平台直接落地到物理服务器上。还有客户为了方便管理，把PaaS落地到IaaS上，两种情况都有。
这其中的考虑是，首先业务量大如果再引入虚拟化这一层会引来额外的复杂度，此时用物理服务器更好。其次，客户有很大规模的物理服务器，直接在上面部署PaaS，在物理服务器上去调用。
第三种，资源动态的调整或资源频繁调配，这个场景很常见，需要IaaS。比如银行客户，内部业务系统分不同的域，不同域的业务复杂性随时间变化经常会发生变化，需要不停地做资源动态的调整。如果用物理机太麻烦，企业客户会选择下面有一层IaaS来做。
基于PaaS也能做一部分的资源动态调配，但是调配维度不同。数人云帮客户落地PaaS时会做资源的整合。从划分的维度，PaaS平台是按照应用程序来划分，IaaS的资源划分是按照业务系统。
Q&A
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还需要很长时间去落地。
SRE（Site Reliability Engineer）即站点可靠性工程师，是一种和传统系统管理员以及普通软件工程师有所区别的新型职业类型。从这张表里我们可以看到这三类人群从工作内容、关注点、技能特长和思维特征都不尽相同。
所以，综上所述可以归纳出SRE应该是这样的人。他们关注问题发生的根本原因，更够通过现象看本质，能够将复杂的问题切分成很多部分，这就是我们常说的决策树。再针对这些拆分的部分提出假设，并进行测试。不断深入不同的分支，直到找到根本的原因。他们能够根据大量信息进行归纳和抽象，以便进行深入的调查。基于现有数据和经验进行判断，拒绝主观的臆断。他们不拘泥于现成的“最佳方案”而是根据实际情况追求各方诉求的动态平衡。不但解决眼前出现的问题，还会预见未来的风险和扩展可能性，从而设计出有长远目标的实施方案。最后他们不默守陈规，勇于拥抱变化，不断打破旧的经验，重复造轮。
如何培养一个合格的SRE，Google也积累了一些内容和方法。这张图内包含了SRE团队可以采用的几个培训新员工的最佳实践，同时保证老员工不会落伍。从下面描述的很多个工具中，我们可以从中选择最适合团队的几个来使用。
故障处理分角色演习
回到最开始，Google SRE的VP叫Ben Treynor，他是一个资深的软件开发经理。2003年他加入公司第一个任务，是组建一个7人的“生产运维小组”。很快他发现如果想把这件事情做好，也就是把搜索服务运维好的话，按照Google机器增加的速度，传统的模式绝对是不可能的。机器增加的速度，系统复杂度增加的速度远比人增加的速度要多得多。所以他组建的团队有以下三个特点，注意，这里我认为其实更多的是事后的总结。首先，他的执行方式是像组建一个研发团队一样来组建这个运维团队。他招了很多他熟悉的研发工程师，这些研发工程师从开发能力上没有任何问题，用现在流行的话就是全栈工程师，什么都会做。第二点，这些人对系统管理比较有热情，懂一些Linux内核知识、网络层的知识。第三点，最关键的是这些人鄙视重复性劳动，码农最痛恨的是什么事，就是反复做同一件事。他把这些人聚到一块，然后让他们执行以前传统公司运维人员来做的事情，很自然这些人不愿意手动干，于是就写程序干。多快好省，同时写程序还有一个好处，就是可以把一些最佳实践、方式、流程、方法都固化成代码，用这种方式去应对规模性的扩张，去应对复杂度的上升。
