云片、网易云联合主办的技术沙龙，《微服务架构落地的最佳实践》在武汉成功落下帷幕！今后我们将陆续推出各位导师的现场视频及 PPT，希望对大家有帮助！
文字整理
主持人：
袁梓超，网易云企业解决方案资深架构师。
10 年以上企业信息化架构经验，在某知名外企从事研发及架构设计工作，曾多次为多个大型企业项目做出整体信息化架构设计，对传统 IT 和互联网技术有独到的见解，擅长企业信息技术上云以及用微服务帮助企业互联化。接下来，他将带来《微服务在传统领域的落地实践》主题分享。
导师：
感谢各位。
我来自网易杭州研究院，网易的技术部门，大家对网易了解比较多的是，网易的邮箱、网易的游戏、云音乐等，但是网易其实有个最大的部门，网易研究院，是这所有产品的公共技术平台，所以我们的很多产品都是基于杭研院孵化出来的。大家比较熟悉的网易云音乐、严选都是杭研院孵化出来的。
2016 年的时候，开始做对外做云服务，所以有很多企业在近两年找到我们，做一些技术合作，主要是云计算、大数据和现在比较火的微服务。网易在微服务落地实践上发展的比较早。
今天，我给大家分享一下，我们目前在合作，我觉得比较典型的微服务案例。 技术是死的，网易虽然有七大公共技术服务，但网易每个技术都是业务部门的需求而研发出来的，而不是我们自己在实验室 yy 这些技术。 所以，基于这些前提条件下，我们现在所有的落地的形态都不一样，大家对微服务的诉求也是不一样的。
举一个例子，证券类型的客户。证券、银行等金融业的客户需求都比较统一，像金融等传统领域 IT 的信息化我相信各位都有相同的认知，金融业的 IT 信息技术是相对领先的。 所以，他们在微服务的实践相对于领先比如制造等行业，他们对微服务的需求更贴向于业务，怎么支持互联网这种快速迭代的需求，怎么支持平台的稳定性安全性的需求。
因为，打个比方，包括最传统的银行业都会有自己的网上银行甚至信用卡的系统，这些都是 2C 的场景，这些对我们常见的 2B 的 IT 架构相比其实是有不同的需求的。
做了微服务架构改造, 那微服务，是一种比较好的，能够提供这种需求及迭代响应能力的这种架构，所以他们在微服务的探索里面往往会领先其他行业更多一些。
像这个证券领域的客户，他对我们提的需求就是这样的，要开拓更多的线上业务，基本所有的线下业务都要慢慢地往线上转，慢慢传统线下的业务形态在往线上走。所有，证券行业对 IT 的要求就越来越高。
基于这些整体条件下，我们跟客户讨论方案落地的时候，提供了一个技术方案，分了不同步骤去做的，这里面也用到了微服务、容器等。那到底怎么去做呢？ 我们分了几块去做：
- 我需要一个比较好的业务响应的能力，需要做一些动态服务的拆分，需要做共享能力的构建，所以第一步我们要做的是动态服务的架构设计。那要完成这样一个架构设计，我们用只做服务拆分就能够做到的，因为我有了这样一个架构设计理念后，怎么去支持他，所以我们选用了容器的技术。容器更为轻量，更为容易地支持我们的微服务，而服务横向扩展的时候，由容器来支持，比传统的效率更高一些。
- 建立好底层的支撑之后，第二件事就是我们怎么去做服务化的治理，服务化的拆分，我们刚才也讲到传统的业务领域，其实微服务会拆得更细一点，拆了之后，需要对服务进行管理和治理。原来一个应用里面，3 到 5 个服务，拆分为三五百个微服务，怎么去管理调度链，怎么去运维，这些都是后续会遇到的问题，所以，我们在里面要做的是后续给他提供服务器管理这样一些能力在里面。保证了这个平台的落地。
所以，我觉的这是典型的对于业务端的需求，因为在 IT 的架构领域里面，我们谈到服务化这层基本上是非常偏于应用的，所以这种应用的改变，往往是来自于业务部门提给我们的诉求，所以我觉得，像金融业现在最典型的是他能更多使用 IT 在支撑业务，跟我们传统的想法不一样，以前建 IT 只是为了建一个单一系统去管理某一件事情，而不是真正得说公司的业务真正在做什么，所以这是现在 IT 和原来传统 IT 最大的区别。
现在对 IT 的整个架构及能力的要求也会越来越高，我相信在做各位的公司也在逐步感受到这一点，对 IT 的投入在不断增大，因为大家希望通过 IT 帮我们的业务增值。这是一个很基础的出发点。
第二个方案，这是一个做安防的客户，制造业。制造业相对于金融业会弱后一些，但是制造业相对于很多传统领域包括教育、医疗领域，我认为在信息化上属于第二梯队的，他们的 IT 属于还在做虚拟化这样一个阶段，但是他们为什么会接触到微服务呢？
就是因为在他们的整个业务发展过程中，遇到了一个新的挑战。因为所有的传统的制造业有一个很大的特点，所有的 IT 系统都是根据产品线来建设的。
打个比方，这个客户他是做监控摄像头的，他的 IT 就很典型，摄像头在不同的场地去使用的，所有的 IT 系统都是以摄像头这种产品服务的，每一个产品生产线几乎都有一条 IT 管理系统去管理这些东西。现在重点来了，现在传统的领域都在做一些智慧城市、智慧社区，这个时候可能就需要做到，把很多产品线打包整合出整体解决方案出来，这个时候就需要 IT 很多信息都是跨系统跨业务的，试想一下，在原来的 IT 架构之下，我要跨部门去同步信息，从组织管理的原则上就很难做到了，所以，这就给他们的老大带来了很大的挑战，我怎样去支撑我的新业务的产生，新业务的增长又明显高于我原来的业务，我的 IT 架构就必须要从根上去解决架构的问题。
所以，在落地的产品里面，我们提供了一个中台的解决方案，但它又有很重的 IT 包袱，我们不能说摒弃原来的 IT 技术，所以我们做了一个类似于服务治理的一个工作。我把很多公用服务抽出来，做了一个叫服务中心的模块，这个模块我们穿插了很多微服务的 API 出来，如果未来还有新的业务需求，可以再去迭代开发。
对客户的管理者而言，在这一块领域是很重的一块内容，对于这一块支撑的要求就和原来的不一样。他要有一个很强的横向扩展能力和未来的调度能力，需要一个很好的技术底层来支撑。采用微服务的架构也是用容器的技术去做的，考虑原来的历史技术包袱，也把新的技术需求涵盖在内了。所以，这个也是在传统领域微服务落地的一个比较好的场景。
这个客户主要做大件物流，大件包裹。但是现在所有的物流公司其实都在拓新的生态，小件个人快递这一块，因为这一块的市场比较大。这个企业原来是做大型物流的到 2C 做快递业务其实遇到的最大问题是，系统撑不住了！2016 年的时候上半年增长达到了 100%，下半年就往下跌，没有办法去拓业务，他的系统支持不了，只有控制自己收缩，因此，2016 年这个客户的 IT 团队由 100 人扩充到 1200 人，用于系统的改造建设。
德邦在国内快递行业已经是前几了，就是因为其在 2016 年的时候做了一个很大的决策，核心业务的微服务化改造，支持其高并发需求，计时系统、订单系统、物流系统基本上都在微服务的架构中。但是在接触德邦之前，他自己已经在做这件事了，基于 Dubbo 的框架，做了一些改造。
做了之后，发现后面带来的技术的挑战会越来越大，微服务对于传统的开发来说，设计很简单，但是真正把业务系统全部做成服务化以后，发现带来很多无穷尽的问题，需要投入精力去研究的，比如说我的服务多了以后，怎么去制定一个统一的标准大家来开发这个服务，第二我的服务怎么去管理，第三服务多了以后怎么去运维，第四多人运行开发的时候怎么做项目管理，其实这都是在做微服务之后带给各位的技术上的挑战。
基于这个，我们给客户提供了底层的微服务框架，就是我们现在网易自己在用的，完成了一些基础的服务治理管理包括品牌建设、资源管理的这些事情。
做了微服务架构改造及提升后，他的运维节省了很多人，一年节省了上千万的成本。这对于做 IT 的人向老板汇报，这是一个很有价值的点。
以上说的是案例场景的事情，今天是个技术论坛，多讲一些干货，到底这些技术的本质区别在哪里？
刚才提到，传统企业的三大 IT 架构分为 IT 架构、应用架构、数据架构。
IT 架构其实这些年很多都能够做到的，都在解决私人的高效利用问题，已经非常成熟了。
数据架构，数据的挖掘、打通，建设大数据仓库，甚至现在的人工智能都是在解决数据架构的问题。
滴滴打车、共享单车以上还是 IT 的基础架构，现在大家关注的应用架构。现在企业对 IT 的要求更多的是，IT 系统能够更多地辅助业务。大家看到很多的新的业务形态是以前没有考虑过的，滴滴打车、共享单车、外卖，这些都是因为 IT 系统能够辅助做业务了，创新做一些业务形态出来，以前的 IT 可能是不会想到的。
既然 IT 能做这些事情，传统企业也能利用 IT 做一些互联网形态下的创新。所以大家开始关注这个领域里了。
但也有些弊端，因为传统的 IT 所有的系统都是基于管理的视角出发的，不管是 OA 文档管理也好，还是跟我们业务有关的 ERP 系统也好，这些都是以业务单元关系部门为视角建立的。这些系统在天然的角度是独立的，很难跟别的系统融合，除非我们开放一些借口才能做到。
但是互联网公司的建设思路是不一样的，互联网公司的 IT 系统我们都是从业务视角出发的。
比如说我们的云音乐，先建个音乐仓库，再建个视频的模块。得先了解这个音乐业务形态是怎么样的，需要什么功能来支撑我的业务形态，最后再把 IT 系统做出来，就不会出现说每个系统都是为了单个环节单元而建立的，先有业务再有系统。
所以这也是现在 IT 互联网公司的系统更灵活些，敏捷性更高一些，因为在最早建设设计的时候就是从前往后推的，跟传统领域我们先做好后面的再去做业务是不一样。
网易现在明星产品有几十款，但是每天孵化的产品有好几百款。不只是网易，腾讯阿里都是这样小而创新的团队。
小团队需要大家一起协作开发，怎么样控制成本，怎么样去提升效率，这样才是我们要考虑的问题。虽然每天有很多产品孵化出来，但是也有很多的产品死掉。
能推出来的产品都是业务形态在网易的模式下，能够得到市场的认可，我们要实践这个模式，不能完全烧钱去做，只有说在最低成本下保证创新。所以说能不能有很多东西大家共用，这样能够提高效率。在我们的整个组织体系里，我们能把基础设施、技术能力，能共用的就共用起来。
在 2015 年之前，网易很少有 2C 的业务，只有游戏最赚钱，然后是 163 邮箱。但这两年，我们有考拉，有严选，有云音乐，有未央等基本都是在这里推出来的。因为我们在 2015 年做了一个大的结构调整。原来网易最早成立是在广州，后来建了一个研发中心在杭州，杭州现在为全国的提供技术支持。
举个例子，网易博客这个产品。
在零几年的时候，做博客这样的业务，大家觉得是赚钱的。但是开始做了以后发现挑战很大。因为我们最早的博客是一个开源的框架改的，但是这个框架的深度及可变性不强，而且在零几年博客是一个比较新的业务，市场对这个产品的要求比较高，每天都加班去修改产品的需求，前端的需求，会带来非常大的挑战，甚至有的时候经常做不到，甚至做出来以后也比市场晚，产品就被淘汰掉了。如果我们当时有一个很好的架构，我相信以网易现在的技术能力，我们也能赶上这一波浪潮。
当时博客首先要很多不同的功能，不同的形态，业务会日渐复杂。先做服务化的拆分。因为所有的应用并发在支撑不住的时候，最简单的方法是加机器，加 CPU 加内存条，但你的应用很耦合的时候，CPU 加得再多性能是死活也上不去的，这个时候是最头疼的问题了。所有当时博客最本质的问题是，我们必须要做服务化的拆分。
服务化拆分之后发现这只是其中一个产品，发现很多产品都有同样的问题。
对于拆分这个事，情，每个团队开发，每个团队都会有自己的标准，我拆好后，这些服务需要怎么布，需要什么样的机器。然后运维发现，为了支撑这样的业务布置，光是采购机器都疯掉了。
所以第一件事就是回炉重造，所有的东西做标准化。
所以，我们 2012 年开始应用上云，2015 年开始做容器化，因为这些所有的东西给我们运维带来了很大的消耗。
但是现在网易所有的机型统一到 5 款，所以这是第一件事情。
那么第二件事情，我们解决了资源的问题，解决了做服务化拆分，但带来了团队协作上的问题。
当你做服务化拆分，我们并行去开发，分布式开发，这个时候怎么去提交代码就带来很大的问题。所以我们就打造了 CI/CD 流水线，非常自动化的体系。
我们基于 docker 技术，运维人员去写 docker 内核，开发人员去写容器环境，我们有统一的代码仓库、统一的镜像仓库，统一的流水线，来做发布和执行。所以现在网易的内部流程，研发人员只用写分到的应用代码就行了，写完之后，提交到执行，再到自动化测试的环节。所以这一款解决了我们团队协作的问题。
解决了上面的问题后，又有一些问题出现了，变得越来越多，服务的链路变得越来越长。
举个例子，电商的核心功能就是下单，如果说我原来写好的支付、优惠券、查库存写到一个服务器里。这个时候你会发现，今天如果支付环节性能下降，就会严重影响下单的流程，那我们只能把他拆成几个服务，支付是支付、减库存是减库存、优惠券是优惠券，这样拆越分越细，我们的服务越来越多，服务的管理其实是很大的问题。
突然有一天发现，有一个功能出现问题，都不知道到底是哪个服务出现问题。在这个背景下，我们就开发了 API 权限的应用监控系统，每天都会把服务的调用链路看一下，看哪些调用延迟比较高，把调用延迟高的解决掉，整个性能就上去了。
所以在服务化的过程中，我们在不断开发一些工具来保障这些事情。有了这些后，发现 API 的管理也是其中一部分，因为服务多了，版本多了，应用多了以后，API 的管理也成为了问题。所以我们又做了 API 的网关。
有了这些之后，我们又解决了自动运维的问题。
比如说，我的应用性能压力大，高并发的时候能否自动去扩容。网易考拉，双十一的时候，预留一个，性能上来，自动扩容到 100 个 1000 个高并发，这就是一个网易比较好的运维了。
考拉属于比较明星的产品了，很多人经常会问我，我们在考拉服务化改造的时候是怎么去做的？
网易考拉这一个应用就有上千个服务，像这样的应用在网易的内部是很多的。
考拉第一版上线的时候，为了赶工期做的应用的结构也比较粗，双 11 的时候也属于烧香拜佛的状态。
这两年我们才比较放心的，就是因为我们做了比较好的服务化了，做了服务化的拆分，有了些自动化运维的原则。比如说下单这个事情，怎么会放到这个优先级，因为下单这个事情会涉及减优惠券的事情，双十一的时候客户的优惠力度很大，减优惠券的服务调用最多，所以要弹性扩容到千个或万个容器来增加服务的稳定，才能保证下单行为的稳定，我甚至能把支付的资源倾向过下单减优惠券的服务上去。
在整个资源池中，我们现在能做到一个比较好的自动运维体系。而且我们会辅助一些手段，比如说每次双 11 之前，我们会拿生态环境做一些压测，拿一些真实的流量做压测，拿几万个容器做压测，压测完有可能环境就脏掉了，因为全是容器化的，就把整个容器迭代滚一遍，这样就是新的容器去支撑双 11.
所以，我们现在的应用都能够很好的支撑，因为我们底层用的是容器化技术和微服务这样的架构。
而且现在版本的迭代，可以达到每天发布两次，上午一次，下午一次，两个新功能版本的迭代，对 C 端的无感的情况下发布两次，这是一个比较高效的协同能力。
刚才提到这些技术，我们自己内部有个名字，叫轻舟微服务。
其实他是一套整体的解决方案。
我们其实一开始我们没有做这么全，这些技术我们内部基本一直在用，陆陆续续有很多客户找我们要其中的一些模块，所以我们把它们打包到一起。
底层的容器平台，这就是简单基础的，所以很多应用多是用的是容器的技术，有了容器的技术后可以做服务化的管理、拆分、治理、搭建。基本上每个小的模块都是一个技术栈。
有了服务化这块内容后，然后就是两块东西，一个是运维保障，一个是链路追踪。然后就是 CI/CD 自动化流水线，基本以上就是我们全技术栈的框架。
最后分享自己之前看到的一句话。微服务这东西，我们为什么要去做？一直是我很让我迷惑的，微服务分布式开发相比传统的开发方式，反而会增加开发者的工作量，为什么要去做？
我们的代码有多好？ 不够好
所以我们才需要一个可持续优化和迭代的环境和流程！
谢谢大家！
