作者：薛浩
出版社：人民邮电出版社有限公司
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
大型企业微服务架构实践与运营试读：
前言
做IT，始于颜值、陷于挑战、忠于兴趣。毕业以后我被“IT”“通信”靓丽光环吸引，加入亚信科技平台架构部工作，从一名程序员成长为技术总监，见证了电信十年的软件架构变迁。十年磨一剑，十年的专注、十年的不离不弃、十年的不懈努力，让我们完成了电信IT支撑系统从MVC单体架构到微服务架构平台的演进，并在公司内外部塑造了一个品牌，倾注了自己的青春梦想。
宝剑锋从磨砺出，梅花香自苦寒来。在漫长的演进过程中，伴随着大量工程实施，我们经历了大大小小几百个战役。只有参与过战斗的人才能体会到收获的来之不易。在经历了“X86”化、“微服务”化、“PaaS”化后，目前平台正向着“ABC”（AI+Big Data+Cloud）化迈进。微服务架构平台的演进落地印证了“精品源于实践”。我们的技术未必是最先进的，但在这个行业是最合适的，我们对此很有自信，这种自信来源于对这个行业的深刻理解，来源于对整个IT技术发展的洞察和预研。
工作十年至今，试点、上线、解决故障、规划、演进、落地推广等工作占据了我大量的时间和精力。目前产品方向已基本确定，演进迭代也在有序地推进，我才能够抽出些时间把多年来积累的经验落在笔下，这也是对十年工作的一个总结。
本书把电信IT业务支撑系统比作大象，讲述了如何通过一步步的架构升级让大象学会跳舞，这也是架构研发的主要目的。本书共分为4部分，15章。第一部分主要解析行业背景，讲述了电信业务的发展历程和IT业务支撑系统的演进历史，分析了电信与电商模式上的主要区别以及如何让大象学会跳舞。第二部分讲述微服务架构的基本知识，分享了早期如何同运营商一步步地进行IT系统微服务架构的探索和实践，并介绍了微服务架构基础组件的设计和实现。第三部分主要讲述了企业级微服务架构的关注点及其必备能力，即在微服务架构的基础上更进一步构建比较完善的“PaaS”平台，讲述了应用托管、服务治理、DevOps等在“PaaS”平台化过程中的作用和实现。第四部分讲述了一些面向未来的架构实践和展望。
本书主要从实践的角度描述打造企业微服务架构平台的过程，除了一些有创意的代码，主要侧重于过程方法和方案的说明。“他山之石，可以攻玉”，希望本书能够让更多企业的IT开发人员、架构师和规划专家从中获取有价值的信息，希望能够让电信行业IT从业人员对业务支撑系统有一个更全面的了解。此外，本书对于想了解电信行业IT发展历史的读者，也是一本不错的入门书籍。全书由薛浩主笔，曹向辉负责全书统稿并完成第1、2、9、10、11章的初稿，他们是对本书的主要贡献者，刘尧、邵玉梅、苗森等负责编辑策划。
想写的东西很多，由于时间关系，实在没有太多精力投入，仓促完稿之际，感慨万千。此书的完成，是亚信人集体智慧的结晶，也离不开大家的帮助与支持，更离不开我们长久服务的电信客户的支持，是他们为PaaS平台的发展提供了成长的土壤。
能够完成本书需要感谢很多人：
首先感谢客户给予我们技术落地的机会，尤其感谢浙江移动王晓征先生等对前瞻性技术推动的支持和理解，那些年联合研发和你们一起经历的困难，是我们共同成长的印记；
感谢公司，何其有幸，何等荣耀，在亚信产业互联网2.0升级的道路上有这么一段奋斗的岁月，有这么一段激情燃烧的青春；感谢亚信公司为产品研发提供了足够大的空间和舞台。
感谢亚信集团董事长田溯宁博士、亚信科技CEO高念书先生、副总裁兼商业发展中心总经理王力平女士、副总裁兼CTO欧阳晔博士、CRM研发中心总经理王鹏先生、CRM业务架构师张峰先生对PaaS平台的总体指导；感谢一直以来并肩奋战在一线的王亮、王峰、刘尧、陈龙、吴宗泽、林国明、袁志勇、梁勇等（排名按姓氏笔画）团队成员，同心协力、激情付出，做出了一款有影响力的产品。
感谢亚信高级副总裁兼首席人力官吕守升先生、亚信学院院长吴晓洁女士、TM Forum高级技术协作总监徐俊杰先生对图书出版给予的支持，还有很多默默支持我们的领导和同事们，在此一并表示感谢。亚信科技AIF产品研发总监 薛浩2018年8月20日第一部分 电信行业架构综述第1章 认识大象
大象给人的印象是体形庞大、行动迟缓，“大象”这个词也是电信行业内部对老系统的一贯称谓。“大象”的比喻一方面说明传统业务支撑系统经过多年积累变得越来越庞大，另一方面也说明传统的运维模式已不能满足当下敏捷的业务支撑响应要求，这与以互联网为代表的新兴软件行业形成了极大的反差。
比较传统与新兴两大行业，同样是IT软件从业人员，却存在截然不同的工作状态，这从两者的朋友圈分享就可以看出差别。从事传统企业IT软件开发的团队分享的以项目上线、加班、熬夜居多，而互联网公司IT开发团队则是以新技术分享、创新实践居多。是什么造成两者工作状态的巨大差别呢？本章将带领大家认识一下电信行业中的“大象”。1.1 何谓大象
本书中的“大象”是对复杂、聚合、大型业务系统的一种比喻。由于本书是基于电信业务支撑系统的微服务架构实践，这里的“大象”也可理解为电信业务支撑系统（BSS，Business Supporting System）。
21世纪的前十年，通信行业的IT圈可以说是国内最热闹的IT圈，后来随着互联网、电商的迅猛发展，电信IT风头不再，跌入到“传统IT”的圈子，在IT建设、系统运营管理等方面相较于互联网有很大的差别。经过十几年的快速发展，电信行业IT系统变得巨大臃肿、步履蹒跚。以业务支撑系统为例，一个EAR包400多兆，包含二十多个大的业务模块，模块间边界模糊、交叉重叠。由于整个团队都是分块作业，大家各司其职，系统对于他们来说如同盲人摸象（如图1-1所示）、不识全貌，这些都给系统运维带来极大的压力。
每周一到两次的新业务上线，对一段代码的修改引发关联性问题的情况时有发生，让人防不胜防。开发运维人员每次上线发布都是通宵达旦、提心吊胆。面对问题的无助、命令行的无奈、回退时的沮丧，给开发运维人员造成了极大的心理压力。
如何才能消除IT人员的无助感，让系统变得轻盈、敏捷呢？图1-1 盲人摸象
小规模迭代，全天候发布，前端无感、后端无痛是我们的目标，也是技术变革的价值所在。然而，变革是要付出代价的，会面临很多阻碍，最大的挑战莫过于业务方对技术变革产生的价值认可。新技术、新思路的推进都不会一帆风顺，如同当年蒸汽机的发明，在当时马车占主要地位的欧洲各国，蒸汽火车处处受到非难和排挤。
只有接受变化、拥抱变革，才能推动助力社会的快速发展。当下，我们生活在“最好的时代”，人们思想开放、积极进取，必将助力我们紧跟技术潮流，实现企业的梦想。
如图1-2所示的“让大象学会跳舞”是我们的目标，也是我们对传统架构的使命。结合企业业务特点，把握技术发展趋势，大胆尝试、小心践行，我们的心愿必将实现。图1-2 让大象学会跳舞1.2 电信业务支撑系统的发展历程
电信业务支撑系统随着电信技术的快速迭代而不断发展和壮大。近二十年，电信行业进入了爆发期，业务支撑系统也随之迎来了黄金发展期。回顾业务支撑系统发展历程，该历程大致可分为4个阶段：初始阶段、成型阶段、稳定阶段和变革阶段（如图1-3所示）。图1-3 业务支撑系统发展历程
1.初始阶段
20世纪80年代，拥有9亿人口的中国，电话用户数仅为280多万，电话普及率为0.43%。当时还是政企合一，邮电部既是电信行业的主管部门，又是电信运营商，主要的工作重点是建设和完善电信基础设施，由于信息技术还不发达，因此国内并没有真正意义上的运营支撑系统。在80年代中后期，随着程控数字交换机的上线，出现了简单的计费和网管系统。但是这些软件仅限于本厂家的设备，功能单一且规模小。从80年代后期到1997年，随着网络规模的快速扩大，产生了具备跨厂商设备管理能力的网管系统。随着用户规模的扩大以及移动通信网的建设，计费系统也开始发展起来。这些都是由邮电部组织和委托高校和科研机构开发的，并没有独立的软件企业和专业人员进行相关的软件开发工作。随着用户数和业务量的爆发式增长，电信的服务和管理水平遇到了发展瓶颈，为了解决日益增长的用户需求与落后的服务手段之间的矛盾，1995年5月，邮电部电信总局提出开发和建设“市内电话业务计算机综合管理系统”，即“九七工程”。“九七工程”是一个里程碑，它拉开了业务支撑系统建设的序幕。
2.成型阶段
从1997年到2008年，业务支撑系统进入了快速发展阶段，这个阶段也是我国电信改革最为剧烈的一段时间。电信企业经过几次大的拆分与重组，到2008年电信市场完成了从业务专营到三足鼎立全牌照运营（三足指中国移动、中国电信、中国联通）的转变，市场竞争格局逐步形成。这种转变直接促进了电信运营支撑系统的蓬勃发展，电信运营商经过系统选型、试错、定型，已基本确定了适合自己的业务支撑系统，合作厂家也从原来的十几家逐渐稳定到了四五家。这个阶段中国电信重新对“九七工程”进行改造，使它从传统的业务计费功能转变到全业务的运行支撑，CTG-MBOSS开始稳步发展。中国联通也完成了系统集中化建设，开始向全国集中化迈进。此时，中国移动凭借成功的系统建设策略和强大资金优势，将众多合作伙伴吸引到自己身边，并将资源的优势化为胜势，规划、建设齐头并进，BOSS建设跨入NGBOSS时代。
3.稳定阶段
2008年以后，经过多年的系统建设，运营商已经积累了丰富的系统建设经验，对自己的需求和业务支撑系统的发展方向都有了更清晰的认识。随着各运营商业务支撑系统大版本的确定，“统一规划、分步实施”已成为运营商系统建设的主导思想，系统建设从规划到投资立项都进入了相对稳定的状态。运营商几乎每年都会组织技术规范修订，用于指导系统的演进发展。这个阶段，中国移动几乎一年一个版本，完成NGBOSS从1.0到4.5的发展演进过程。中国联通在系统集中化的道路上不断进取，在完成了电子营业厅（ECS）系统建设，并推出了全网统一的业务和产品后，又借着3G的东风与苹果合作，通过控制号码资源和明星终端资源，成功完成了业务集中，建立了集中化的运营体系。中国电信系统建设则一直稳扎稳打，CTG-MBOSS版本从1.0到2.0不断升级，通过规范指导，有效落实IT能力的提升和统一。
4.变革阶段
随着大数据、云计算和互联网的迅猛发展，到了2015年，新技术、新模式、新业务对电信业务支撑系统的影响开始显现，各运营商又开始酝酿新的技术变革。系统云化、微服务化、自动化、智能化成了转型升级的主旋律。中国移动在完成了NGBOSS 4.5的规范建设后，于2015年制订了第三代业务支撑的建设规范。新规范借鉴了互联网企业的系统运维模式和云化的技术发展路线，对技术架构进行了更细层级的划分（CRM系统从原来的三层架构演进为五层架构），对业务架构也进行了重新定义（由单体架构向业务中心建设转型）。中国联通在继续深化CBSS和全国集中化建设的同时，开始专注系统专项能力提升以及智能化、云化和分布式系统建设。2016年，中国电信发布了转型升级新战略，将持续推进企业转型升级3.0，着重推进网络智能化、业务生态化、运营智慧化，致力于打造业界领先的综合智能信息服务运营商。
电信行业是一个比较依赖IT系统的行业。一直以来，电信企业对IT系统的建设和IT技术的发展都非常重视，相较于其他传统企业更加追求技术进步。每次有重大技术变革或理论创新，电信企业都会最先做出反应，敢于尝试。然而，随着近几年互联网企业的崛起，在新兴互联网技术不断涌现的情况下，电信企业受传统业务连续性保障的制约，在新技术、新思想方面的探索和发展相对滞后。
电信业IT系统的发展历程绝对可称得上是一部中国IT技术的发展史。开发语言经历了Fox Base、Power Builder、Delphi、Pro*C到J2EE、JEE的变迁，系统架构经历了单体、C/S架构、B/S架构、SOA，目前已全面实施分布式系统架构。从跟随到引领，电信人从来没有放弃对技术进步的追求。“让技术驱动创新，让软件定义一切”一直是我们前进的方向。1.2.1 “大算盘”时代
前面讲到业务支撑系统的发展经历了四个阶段，支撑系统实现了从无到有，从高速发展到稳定运营的发展过程。这里谈的大算盘时代并没有明确的时间节点，如果非要划个界线，就以邮电部电信总局的“九七工程”为界。“九七工程”的实施，标志着电信业务支撑系统建设的正式起步。
实施“九七工程”前，业务单元都是以市为单位进行运营管理的。当时的业务比较简单，主要围绕着装机、配号、配线展开，计费也比较原始（通过C程序解码交换机上的磁带，计算话费）。各县市资源调配、资源管理依赖于笔记本电脑、Excel。后来相继用Fox Base开发了一些管理系统，这些系统从功能上看基本上是手工操作的模仿和延续，也就是通常所说的“大算盘”。这些系统几乎没有管理功能，可管理性差，更谈不上数据共享、信息传输等现在看来最基础的能力。在当时，软件架构绝对是高大上的东西。
进入20世纪90年代以来，我国电信行业的业务量每年以45%～50%的速度递增。原来的服务手段和管理水平已不能满足业务的发展，装机难、修机难、查询难等成为电信营业部门的心病。为了解决先进的电信网与落后的服务手段不相称而带来的各种问题，1995年5月，邮电部电信总局提出开发和建设“市内电话业务计算机综合管理系统”，即“九七工程”。从此，电信业务支撑系统进入了C/S时代。1.2.2 C/S时代“九七工程”共分为九个子系统。其中，营业受理、配线配号、订单管理、机线资源、综合管理与查询属于基本子系统，112、114、计费、号簿子系统与基本子系统完全实现数据共享。根据电信总局对“九七工程”的实施要求和对各子系统相互之间关系的阐述，以大唐电信为代表的一些厂家基于当时的技术条件，选择Power Builder+Oracle的架构模式，也就是所谓的C/S架构。
然而，Power Builder+Oracle模式并没有持续多长时间，基于安全考虑，要求前端不能直接访问数据库。于是Delphi+Pro*C+Oracle的模式应运而生，这也是最初的三层架构的雏形了（如图1-4所示）。Delphi程序作为客户端负责与用户交互；Pro*C程序运行在CICS中件间提供业务服务，阻断客户端直接访问数据库；Oracle数据库服务器提供数据服务。通过这种三层架构设计，从技术上消除了客户端直接访问数据库带来的风险。图1-4 C/S三层架构
在这个阶段，电信业务的发展也走上快车道。伴随着用户量的不断攀升，移动网络的快速发展，再加上电信企业的拆分、重组以及市场化改革，市场竞争加剧，业务类型不断丰富，管理要求越来越高。这时，C/S程序的数据分散、客户端升级维护麻烦，业务响应慢等弊端开始突显，已经很难满足业务的快速发展。与此同时，B/S程序作为一种新的软件架构模式展现了其强大的生命力。而随着J2EE的不断发展以及大量成功案例的出现，B/S软件架构的企业级应用登上了历史舞台。1.2.3 MVC垂直应用
B/S软件架构的兴起让人们开始憧憬Web程序给客户带来的便利。不用再在每个客户终端安装应用程序，对客户终端的要求变得更简单，只需要能够正常上网即可。同时，软件升级和维护也变得容易，只需要更新服务器上的软件即可，这对客户的人力、物力、时间、费用的节省是显而易见的。Web程序的巨大成功，推动了Java的快速发展，而Java的发展又推动了企业级Web应用的普及。根据J2EE的标准，软件架构分为三个层级（如图1-5所示）。
通常意义上的三层架构就是将整个业务应用划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。每个层次的职责如下。
①表现层（UI）：通俗讲就是展现给用户的界面，负责与用户交互，用于接收用户输入的数据和显示处理后用户需要的数据。
②业务逻辑层（BLL）：表示层和数据访问层之间的桥梁，针对具体问题的操作，负责实现业务逻辑。
③数据访问层（DAL）：负责与数据库打交道。主要实现对数据的增、删、改、查。将存储在数据库中的数据提交给业务层，同时将业务层处理的数据保存到数据库。图1-5 J2EE三层架构
严格来说，MVC不是一种应用架构，它是表现层的一种设计模式。基于表现与数据分离的原则，表现层分为三个模块：Model-View-Controller。由于早期的J2EE应用都是基于MVC的三层架构垂直构建的，所以后来人们也就称这种垂直构建的三层系统为MVC应用，也称为单体架构。MVC系统生态如图1-6所示。图1-6 MVC系统生态
MVC时代的业务支撑系统建设的特点就是造“烟囱”。在信息化大潮下，业务处在高速发展阶段，在先建设再优化的指导思想下，各个运营商都建设了各种各样的数目可观的信息系统，如营业系统、计费系统、渠道系统、决策支持系统等。每个系统由一个或多个厂商承建，自成体系。久而久之，这些系统不仅个体庞大，且相互之间没有通信，就好像一个个的大烟囱。“烟囱”多了，造成了信息孤岛，于是支撑系统又开始踏上打破孤岛、系统整合的道路。主流的EAI整合方式主要有三种：界面集成、服务集成、数据集成。
①界面集成是通过前台框架把不同的系统的页面集成到一个系统中（或称系统门户）。这种方式相对比较简单，也是当初最常用的集成方式。界面集成涉及的关键技术有Portal和单点登录（SSO）。简单地说就是，通过Portal技术把其他系统的相关界面集中到一个门户中，然后通过SSO解决跨系统登录访问的问题。
②服务集成是不同应用系统之间通过共享的服务进行功能的整合和数据同步。它本质上是数据集成的一种服务化的表现形式，是EAI集成的高级阶段。服务集成有力地推动了Web Service、SOA、RPC等技术的发展。
③数据集成是为解决信息孤岛把不同系统的生产数据在逻辑上或物理上进行有效的集中，为企业提供全面的数据共享。数据集成的方式比较多，如联邦数据模式、中间件模式、数据仓库等。电信行业是国内最先尝试数据仓库（中国移动在2001年就开始学习研究数据仓库）的企业，为中国培养了大批的数据工程师。现在很多从事大数据、人工智能方面的中高级人才有电信经营分析的从业背景。
系统建设、系统整合几乎是MVC时代的主旋律。建设初期系统相对比较简单，但是随着时间的推移，业务的不断发展，系统会变得越来越臃肿，关系也变得越来越复杂，给运维带来了很大风险和难度。此外，成本居高不下，重复建设造成了严重的资源浪费。“大象病”就是这么一点点形成的。
如何才能更好地实现服务复用，避免重复建设，简化系统间关系呢？于是，SOA出现了。1.2.4 SOA服务化
SOA是指面向服务的架构，强调以服务为基础搭建的企业IT架构。它通过建立标准解决了服务“复用”和系统间“互操作”等问题。SOA虽然出现很早，但是当时的技术水平和市场环境尚不成熟，并未引起人们的广泛关注，直到Web服务和SOA参考模型的出现，SOA才直正进入高速发展阶段。2005年左右国内外开始有厂商推动ESB产品在运营商系统的落地。
因为电信行业的IT系统间关系并不是简单的平行并列关系，而是“核心+外围”星形模式，所以运营商并没有大规模引入ESB，只是在一些技术先进省份进行试点。调用关系是单向的，一般是外围系统调用核心系统提供的服务，并不太适合ESB的业务场景。再加上ESB的定制能力差，核心系统在服务开放形式上只能以当时最标准的Web Service的形式进行注册和发现，性能上存在严重的问题。因此，在核心业务系统领域，并没有使用ESB产品，而是自建接口平台。
接口平台实现了服务汇集，同时实现了外围系统对核心系统的隔离。以CRM为例， CRM除了提供垂直应用的营业功能外，还对外提供了大量的接口供外围系统调用，如电子渠道、社会渠道、ESOP、网状网以及外部银行、商城等渠道。这些渠道通过接口平台实现了与CRM的通信（如图1-7所示）。图1-7 业务支撑系统SOA
随着服务化的深入、新业务的不断涌现以及市场竞争的加剧，对业务支撑系统的要求越来越高，而上述架构在ESB或接口平台上的瓶颈也日益凸显。原系统架构主要问题表现在：
①缺乏有效的服务治理，服务资产混杂不清，没有有效的服务管控手段；
②业务支撑响应慢，系统尾大不掉，无法做到实时更新和模块化发布；
③系统可用性差，无法做到7×24小时无间断提供服务；
④创新业务难以支撑，特别是带有互联网特点的创新业务，如团购、秒杀等。
传统的SOA模式已很难满足业务的快速发展，急需一种新的架构模式，既要解决单体架构沉重的负担，又要高效率实现服务化的功能，这时微服务架构出现了。1.2.5 微服务架构（MSA）
SOA虽然解决了部分服务复用和系统间整合的问题，但它并没有解决“大象病”带来的系统臃肿、反应迟缓、运维困难的问题。新技术、新业务以及市场竞争的加剧，对系统的业务支撑能力提出了更高的要求，如7×24小时不间隔服务、模块化快速迭代、应用的水平扩展、资源的弹性伸缩等。
认知的提高会催生技术的发展，新的难题一定会有新的解决方案。在这方面，IT领域总不会让人失望。正是由于大家对系统敏捷的追求，对高可用、水平扩展、弹性伸缩的渴望，Docker、DevOps从一出生就高歌猛进，大大加速了微服务架构的推广实践。微服务架构是一种分布式服务架构模型（如图1-8所示），与SOA的主要区别在于一个是分布式调用，另一个是集中式调用。图1-8 微服务架构
面对如此势头，运营商不会无动于衷，于2014年开始规划新一代业务支撑系统的架构演进路线。作为国内最大的电信行业IT解决方案的提供商和服务商，亚信科技一直在跟随世界IT发展趋势，关注着新技术发展动态，不断地尝试新技术的实践方案。
在IT技术领域，没有最好的，只有最合适的。结合对电信行业的理解和系统特点，亚信科技已形成了一套完善的企业级微服务架构。
新架构的主要特点如下。
①分布式：实现了三个层次的分布式，分别为物理部署分布式、服务部署分布式、数据存储分布式。
②高可用：由于分布式架构，再加上服务发现和集群化部署，避免了单点故障可能引起的业务故障。服务自动注册功能又使得系统可以实时发布，实现了系统7×24小时不间断服务。
③可伸缩：正是基于分布式架构高可用设计和动态路由支撑，使得应用对主机的启、停无感知，真正做到按需、随时分配资源。
④运维智能化：服务治理、DevOps实现了应用部署自动化，服务关系可视化，服务状态可控化，资源分配自动化，告警、预警智能化。1.3 电信业务支撑困境
随着技术的发展和业务的增长，电信业务支撑系统的架构和软件开发模式渐渐落后。由于缺乏有效的手段进行服务管理，在系统开发和运维过程中产生了大量冗余、耦合的代码。服务接口重复开发，服务关系错综复杂，业务边界交叉重叠，这给开发和运维带来极大的挑战。需求支撑响应越来越慢，上线故障越来越多，上线时间越来越长，失败次数越来越多，对创新业务的支撑越来越难。系统运维难以为继，运维人员苦不堪言，我们作为其中的一员深有体会。
下面，我们以某省运营商为例，总结了其业务支撑系统存在的问题以及产生问题的原因。
1.重复建设维护成本高
重复建设分两个层面，一是系统层面重复建设，这是由于系统没有统一规划，而系统建设多是由各职能部门和渠道独立建设，业务功能有较多类似或相同，本书在此不做过多的论述。二是服务层面重复开发，这主要与系统架构、软件开发模式有关，造成重复造轮子的严重现象。
由于系统架构缺少有效的代码开发质量管控手段，软件开发还是采用面向过程的开发模式（Server、DAO的开发模式），造成Server成为各种服务的容器。再加上合作伙伴的开发人员流动性大，开发任务重，开发人员为了尽快完成任务，规避风险，往往知道有相同的服务或相似的服务也不敢用，都是先复制，再修改，先保证自己的需求上线再说。久而久之，服务重复越来越严重，业务边界越来越模糊，服务关系越来越复杂。举个例子，在系统中仅客户资料查询就存在180个类似的服务，而一个“Server容器”就有几万行代码，上百种方法，这样的系统很难维护。
2.支撑响应速度慢
支撑响应速度慢除了管理流程方面的原因外，主要还有系统架构的制约。由于系统采用的是单体架构，后台对业务没有进行解耦，所以整个后台服务耦合在一起，每次上线发布都要进行代码的全量编译（一个JAR包），效率低。其次，前后台服务调用采用的是简单的负载转发，没有实现服务的注册、发现，做不到系统的全天候发布，系统升级或新业务上线往往只能在晚上空闲的时间进行。最后，代码管控力度不足，系统可维护性越来越差，开发难度上升，测试耗时增加，再加上厂家人员流动性大，这些都严重影响了业务的支撑响应速度。
3.运维风险不可控
服务运行中出现问题，缺乏有效的管控手段。一个服务出现问题，影响多个业务和渠道，无法预知。如某个业务变更影响了互斥规则校验服务，可能会导致开户、产品变更等大批业务不可用；服务的质量无法保障，如电子渠道进行抢购、秒杀等营销活动时，短时间内产生海量（瞬时并发约20000用户）的互联网订单，造成订单管理系统运行缓慢，营业前台受理受阻，业务无法开展，严重影响客户体验；监控手段缺失，缺少对服务调用，服务质量的监控，无法进行调用链分析和故障传导分析，无法快速、准确地定位问题。
4.创新业务难支撑
近些年随着移动互联网的兴起，“互联网+、大众创业、万众创新”的国家战略实施，彻底激发了人们的想象力，各种创新应用、商业模式层出不穷。面对如潮的创新应用，业务支撑系统明显感到力不从心，无法跟上业务发展的步伐。如某手机电子商城，为了提升客户体验，提升竞争力，想在卖手机的同时能够办理套餐，这样的需求目前就很难满足。还有，对于互联网公司经常使用“秒杀、抢购”等营销活动，业务支撑系统也很难满足。面对市场前景无限的手机类支付创新应用，系统也难有所作为。
事物都是发展变化的，没有什么是一成不变的，IT系统更是如此。系统在建成初期，功能丰富且创新前瞻，很好地满足了当时业务的发展。但是，IT是有时效性的，随着时间增长和业务的变化，IT系统也会出现不适。IT系统发展的历史就是一部业务与技术博弈的发展史，两者呈螺旋上升趋势。业务在很长时间内占据了主导地位，俗称业务定义IT。近些年，技术发展迅猛，正在改变着这个世界，带我们进入了IT定义一切的时代。1.4 电信与电商
电信和电商，一个代表传统，另一个代表新兴。阿里云的王坚博士曾经这么形容这两个行业，传统行业里的一群人，他们的公司赚了不少钱，但是他们整天愁眉苦脸的，表示自己干得多辛苦，多烦躁；新兴行业里的这群人呢，他们的公司没有赚到钱，但是他们整天兴高采烈的，表示自己又怎么怎么进步了。这种情况，恰好反映了电信和电商给从业者带来的感受。
电信主要代表中国移动、中国电信、中国联通这三家通信公司。电商主要指淘宝、京东、苏宁易购、亚马逊等通过互联网进行网上贸易的电子商务公司。电商是一种商业形态，通过互联网进行网上贸易，从这点上讲，任何企业只要有交易都可以做电商。随着国家“互联网+”战略的实施，过不了多久，很多传统企业也都变成“电商”了。
电商的快速发展，对各行各业带来了深刻影响，到处都在讲互联网思维，提互联网转型。电信行业也不例外，运营商纷纷树起改革大旗，进行互联网化转型：体制去电信化，内容互联网化，产品开发运营一体化，运营轻资产化等。本节讲电信与电商的区别，主要是站在业务支撑的角度，分析电信企业与电商企业的差别，为电信企业的互联网转型提供参考。
1.思维方式不同
首先，电信思维是以产品为中心。所以，电信思维一定要把概念、定义、范围等说清楚。其次，电信思维是稳定压倒一切。7×24小时不间断服务，6个9的稳定性要求，都是电信级服务标准的具体体现。“永不消逝的电波”更是通信从业人士的毕生追求。为实现“稳定第一”的目标，就要做到系统的标准规范，行为的整齐划一。最后，电信思维是层级化组织之下的分工协作。管理运作规范比较严格，各个单位和组织都是基于树状结构建立的，跨部门时通常需要上级单位介入，才能很好地沟通协作，因此也呈现出更多的权力和资源的集中化。
什么是互联网思维？首先，互联网思维是以客户为中心。同样从事信息产业，相对于高冷的电信领域，互联网企业更接地气，因此更能与客户产生共鸣。其次，互联网思维说干就干，追求时效。好的创意，好的点子，如果不马上去实现，很可能就会错过“风口”。企业衰落周期随着互联网改变产业的速度在加快，所以“敏捷、高效”是互联网公司的生存之道。最后，互联网思维看重开放合作，注重生态。
正是基于互联网思维，互联网公司的组织架构都比较扁平，组织灵活，一般都是小团队作战。正如康威定律所述架构决定组织，反映在互联网企业的IT架构上就是“小、快、灵”。不需要做一个大而全的产品，而是专注功能，灵活组织、快速迭代。如某电商平台的“大中台，小前台”系统架构，就如美军的“特种部队+航母舰群”的组织结构方式。十几人甚至几人组成的特种部队在战场一线，可以根据实际情况迅速决策，并引导精准打击，而精准打击的导弹往往是从航母舰群上发射而出。
2.客户体系不同
所谓客户体系，是指与客户有关的各种属性值，以及各种属性之间的关系。例如移动客户的属性中，既有个人基础信息（包括姓名、性别、年龄、教育背景、职业等），也有行为信息（活跃度、位置信息、终端等）、消费信息（账单、价值、新业务黏性等）等扩展属性。而对于企业客户来说，客户的模型就完全不一样了。统一账号收敛的只是客户ID，要在建立起一个新的客户编码后，把这些原来千差万别的客户属性梳理组织在一起。
传统的运营商体系是以产品为中心的。无论是固网、宽带，还是移动、IPTV，都是相互独立的运营体系。这种独立最直接的表现就是每个业务都有独立的用户ID：固定用户是本地网号码，移动用户是移动号码，宽带用户也有自己的账号等。目前运营商所谓的客户体系，多是以产品为中心各自建立的，虽然在IT支撑领域实现了一定程度的融合，而且单一业务形态下的客户体系已经比较成熟，但对于统一账号之下的客户体系，在先进性、完整性、适应性等方面还存在比较大的差距。
互联网公司的发展往往都是从一个业务开始，然后再通过不断地创新拓展和兼并整合，扩大业务范围和客户规模。因此互联网公司一般形成了以客户为核心的体系设计，客户单一的ID往往是互联网公司最初或者最核心的业务，再向下分解是各个产品和业务。
3.经营模式不同
运营商与客户之间是租约性交易，一次合约后通过持续运营可以周期性获得收益，所以经营之道在于“建网——营销——运营”，前两步的目的都是为最终能持续收益。另外，大部分运营商采用属地运营模式，这一模式在企业发展初期很好地契合了发展要求，取得了非常好的效果，但是随着传统电信业务的逐渐管道化，新业务发展呈现快速、统一的要求。
互联网与客户之间很少有周期性的付费合约，要么靠营销提成，要么靠后向收费把前向的流量变现。订单转化为收益的周期短，营销成功就意味着胜利。所以我们看到，互联网企业将各种资源都聚焦在营销环节，产品研发、组织架构、管控体系等都是以营销为核心的。另外，互联网公司集中的是整个客户运营体系，为客户集中提供服务，对客户的需求集中响应，集中地为客户解决问题，实现了端到端的集中。第2章 让大象学跳舞
让大象轻盈地舞蹈，离不开合适的舞台和驯兽师对大象身体各部位的控制和调教。大型单体软件系统也一样，要让系统敏捷，也需要一个合适的平台和对软件系统的解耦。2.1 大象能跳舞吗
大象能跳舞吗？答案显然是肯定的。正如前面所讲的业务与技术的辩证关系一样，两者是相互促进、相辅相成的。系统用久了，变得臃肿、迟缓，那一定会有办法让它重新轻盈、敏捷起来。2.2 大象的舞台
究竟搭建什么的舞台才能让大象轻盈地舞蹈呢？
云原生计算基金会（CNCF）给出了答案，在云的时代就要实现云化的应用。这涉及应用的架构、应用的开发方式、应用的部署方式和系统维护技术等方面，真正发挥云的弹性、动态调度、自动伸缩等一些传统IT所不具备的能力。CNCF给出了云原生应用的三大特征。
①容器化封装：以容器为基础，提高整体开发水平，形成代码和组件重用，简化云原生应用程序的维护。在容器中运行应用程序和进程，并作为应用程序部署的独立单元，实现高水平资源隔离。
②动态管理：通过集中式的编排调度系统来动态地管理和调度。
③面向微服务：明确服务间的依赖，互相解耦。
云原生包含了一组应用的模式，用于帮助企业快速、持续、可靠、规模化地交付业务软件。云原生由微服务架构、DevOps和以容器为代表的敏捷基础架构组成（如图2-1所示）。图2-1 云原生能力特征2.3 大象跳舞“四步曲”
虽然运营商支撑系统的转型面临巨大挑战，但我们还是非常有信心通过微服务化实践让这头大象变得轻盈、灵巧。
如何才能让大象舞动起来？笔者认为需要如下四个步骤。
①第一步：搭舞台，基于云原生搭建微服务架构平台；
②第二步：瘦身，按业务领域拆分业务系统，重塑核心能力；
③第三步：学步法，容器化封装应用，实现资源共享和弹性伸缩；
④第四步：轻盈起舞，消息框架开路、数据库筑池、故障自愈、全链路监控、灰度 发布。第二部分 构建微服务架构第3章 微服务架构综述
系统架构发展到今天，进入了微服务架构时代，微服务架构的系统开发与传统单体应用的开发有很大的差别。传统单体应用的开发是业务定义IT，业务在整个系统开发过程中占主导地位。微服务架构的系统开发则是IT定义软件，因为要实现微服务必须是IT架构先行，只有搭建好支撑微服务运行的架构平台，才能够进行微服务的开发或改造，IT架构的好坏直接决定了应用系统的成败。
本章将会介绍微服务的本质，以及企业将如何实践微服务架构。3.1 微服务的本质
微服务的诞生并非偶然，它是软件发展到现阶段的必然产物。随着互联网的高速发展，敏捷、精益、持续交付方法论渐渐深入人心，容器技术和DevOps的成熟应用，再加上传统单体架构无法适应快速业务变化，这些因素都促成了微服务的诞生。微服务将引领软件架构朝着高扩展性、高可用性和弹性计算方向发展。3.1.1 什么是微服务
什么是微服务？顾名思义，微服务要从“微”和“服务”两个词上去理解。微，狭义来讲就是体量小，这里的小是相对的。相对一个系统，一个服务可能占有的空间和资源比较小。而所谓服务，一定要区别于系统，服务是一个或一组相对较小且独立的功能单元，是用户可以感知的最小功能集。
微服务是一种架构风格。一个大型复杂软件系统通常由许多微服务构成，系统中的各个微服务可被独立部署、独自演进，各个微服务之间松耦合，每个微服务代表着一个完整的业务单元。尽管“微服务”这种架构风格并没有精确的定义，但微服务的实施都具备一些共同的特性。
总体来讲，微服务具有以下特点。
1.服务粒度小
在定义微服务的时候，遇到的第一个问题就是如何定义“微”，多小的粒度称为微服务？是这个名字给了大家误导。其实，完全没有必要去追求“微”的尺度，应该回归服务的本质，即应该关注你所设计或划分的业务领域。这里再强调一下，这里的“微”是相对的，真实情况可能并不小。鞋子合不合脚，只有自己知道。微服务也是一样，服务划分的粒度也不是越细越好，应该与自己业务水平和架构能力一致。如果没有好的架构能力，却过分地追求更细的粒度，反而会适得其反。微服务粒度如图3-1所示。图3-1 微服务粒度
在电信行业，通常按业务领域划分不同的业务能力中心，一个能力中心就是一个微服务应用单元，如用户中心、资源中心、订单中心等。
2.功能单一
微服务就像积木，每个积木都有自己的作用，通过积木之间的搭配、组合，能够搭建起具备复杂功能的实体。微服务的设计遵循面向对象设计的单一职责的原则。一个业务系统应该由大量的微服务构成，业务流程通过服务编排去实现，这样系统才具有更大的弹性和可塑性。
微服务越多、越全面，实现一个新业务就会越简单，原来的代码开发可能就变成了流程编排。然而，这里还是要强调一下度的问题，微服务拆分的粒度要与自己的技术和管理水平保持一致。
3.轻量化通信
微服务之间是解耦的，但一个业务功能往往需要多个微服务协作才能完成。因此，服务间如何高效通信就显得非常重要。微服务架构通常会选择与语言和平台无关的轻量化的通信协议，如RESTful风格的API。微服务集成如图3-2所示。图3-2 微服务集成
4.弹性伸缩
微服务是没有状态的，因此，很容易通过实例数的增减实现服务能力的弹性伸缩。由于微服务架构平台原生为微服务提供了负载均衡机制，在需要服务扩容时，仅仅需要创建更多的服务实例即可（如图3-3中的实例5）。图3-3 微服务扩容
5.独立性
每个微服务能够实现独立的开发、测试、部署、演进、多版本发布，具体如图3-4所示。图3-4 微服务独立开发部署
独立部署带来的优势很明显，首先，在生产系统发现功能有缺陷，可以快速对该功能进行回滚，不会影响到整体业务，即使尚未回滚，在系统中影响的仅仅是这一个功能；其次，该微服务能够实现低成本的线性扩展，不像在单体架构中，扩展某一模块的吞吐量，需要增加整个系统的实例；最后，可维护性强，对该模块的升级、修改不需要重启整个应用。3.1.2 微服务架构特点
实施微服务化的系统架构就是微服务架构。微服务架构并不是横空出世，它是业务、技术发展到一定阶段的必然产物。它从SOA架构、分布式服务框架持续演进而来。既然微服务架构是从SOA架构和分布式框架演变而来的，那么它也就兼具两种架构的一些特点。
首先，微服务架构是分布式的。分布式架构系统设计的原则和方法同样适用于微服务架构的系统设计，同样的分布式系统常用的基础设施和中间件（如分布式消息中间件、分布式缓存、分布式事务协调器等）依然是微服务架构中的重要组成部分。如果抛开分布式去谈微服务架构，那就是空谈。
其次，微服务架构与SOA架构一样，与开发语言无关，它并没有一个被严格定义的标准规范和实施指南，更多体现的是一种设计理念和指导思想，归纳以下几点。
①轻量级的服务：每个服务实例只提供与自己密切相关的一种或几种服务，粒度小、量级轻，便于微团队快速开发、部署、测试与升级。
②松耦合的系统：微服务之间的调用也是客户端的一种调用方式，仅限于接口层的耦合，避免了服务实现层的深度耦合。因此服务之间的依赖性被降到了最低，系统的整体稳定性与平滑升级能力得到了提升。
③水平扩容能力：由于微服务架构中都原生地提供了服务调用均衡机制，因此对于无状态的微服务，可以通过独立部署多个服务进程实例来提升整体的吞吐量。由于每个微服务可以单独扩容，因此微服务架构具有很强的运行时的性能调优能力。
④积木式的系统： 每个微服务通常被设计为复杂业务流程中一个最小粒度的逻辑单元，一个完整的业务流程通过编排这些微服务而形成的工作流。这样，升级或者新开发一个新业务流程就变成了简单的积木游戏。而随着微服务越来越多，它的复用价值越来越大，因此新业务快速上线的要求就变成了一个可准确评估和预测的计划 任务。3.1.3 SOA与微服务
SOA是一种架构思想，微服务是对SOA的进一步深化和发扬（SOA与微服务的关系如图3-5所示）。SOA要求系统间通过服务化实现互联，通过服务编排实现快速能力响应，但在SOA的实践过程中，ESB这种集中式的服务管控模式成为SOA的实施标准。微服务是分布式调用模式，在实践过程中为了服务治理的需要，微服务架构引入API Gateway以实现集中管控，于是就形成了如今的集中管控、分散调用的微服务架构模式（注意API Gateway与ESB是以不同的形式存在的）。图3-5 SOA与微服务的关系
区分微服务架构与SOA主要体现在架构实践和服务间的通信方式及管控模式上。两者在服务间通信方式及管控模式方面的不同，也就是ESB与API Gateway之间的差别。ESB采用的是集中管控、集中调用的方式，通信方式通常采用与语言无关的WS方式。而API Gateway则只负责服务管控和服务路由，不包括服务调用过程。微服务通常采用简单轻量级协议，如REST。
在架构实践上，伴随过去十几年互联网行业的高速发展，以及敏捷、持续集成、持续交付、云技术等的深入人心，微服务架构的开发、测试、部署以及监控等方面相比传统的SOA实现，已经大相径庭。主要区别如表3-1所示。表3-1 SOA实现与微服务架构实现的对比3.2 实现微服务架构
微服务的架构思想是好的，但要大规模地推广实施，还需要相应的配套技术支持。
微服务功能单一，粒度小。如果把一个系统拆分成很多微服务，还采用以前单体应用的运维方式，则会在系统的运维上形成瓶颈，可能达不到人们想要实施微服务的结果。试想，谁能维护成千上万的微服务实例呢？因此，容器化封装、自动化部署对于微服务架构来讲是必需的。微服务架构需要提供对微服务全面的监控管理，让开发人员真正专注于服务的开发。
2014年，Docker发布了1.0版本，迅速点燃了业界对微服务的热情。与此同时，DevOps作为实现微服务的标配也一同进入了人们的视野，甚至连一直不温不火的PaaS平台圈也开始热闹起来。
Docker封装了应用以及相应的依赖，实现了一次构建，随处运行。测试人员无须再为搭建测试环境而苦恼，也不必为测试与生产环境不一致造成的困惑而苦恼。
有了Docker还不够。系统拆解后，采用的都是分布式集群部署方式，这样就引出了新问题：如何管理众多的容器和容器间的通信？这时Kubernetes出现了。Kubernetes是Google公司推出的容器集群管理调度平台。该平台向下提供对底层资源的虚拟化以及管理功能，为上层应用的部署提供资源调度，向上提供了应用的托管功能。应用以容器镜像的方式部署，平台为应用提供了故障自愈，扩、缩容等特性，大大简化了维护的复杂性。Kubernetes与Docker的结合推动了微服务架构在企业的实践。3.2.1 微服务参考架构
一个完整的微服务架构由多个要素构成，不像ESB之于SOA一样，确切地讲，它更像一个生态圈（如图3-6所示）。实现微服务不但需要基础设施的配合，还要有生产环节部门的协同；不但要有系统运行时的管理控制，还要有服务治理的安全保障，这些都是由微服务的特点决定的。图3-6 微服务架构生态图
微服务架构与垂直单体架构不同，是由一系列职责单一的细粒度服务构成的分布式网状结构，服务之间通过轻量机制进行通信，基于传统的静态网络地址的服务调用方式已不能满足需求。因此，微服务架构必然需要引入一种新的服务调用方式，即分布式服务调用。由于服务提供方都是以集群方式提供服务的，所以微服务架构必须能够实现负载均衡的能力。微服务化后，服务之间会有错综复杂的依赖关系，往往也不是百分百可靠，可能会出错或者产生延迟。如果一个应用不能对其依赖的故障进行容错和隔离，就会引起系统雪崩，所以一些针对服务调用的安全管控措施也是必不可少的。在微服务架构中，完成一笔业务可能需要调用很多微服务，也会跨越很多不同的容器和主机。这样一旦出现问题，传统的方式——根据日志去定位问题，那基本是行不通的，这时就需要平台能够提供分布式服务调用链跟踪分析能力。同样，微服务化后，原来的一个系统变成许多微服务，传统的部署方式已无能为力，自动化部署成为必然的选择。基于服务治理和系统安全考虑，需要对分散的服务进行集中管控，因此，服务网关也成为必然选择。
总之，微服务架构的实现必须具备以下能力。
1.分布式服务调用
微服务天然是分布式服务，因此，服务的调用方式从单体的进程内调用（IPC）转变为进程间调用（RPC）。由于资源云化，服务实例在运行时的配置会动态变化，包括它们的网络地址。因此，分布式服务调用框架是微服务架构的基础，其核心是服务的注册与发现。
2.服务网关
为了保障生产系统的安全性和服务治理的需要，鉴权和相应的安全措施是必需的。然而，如果为了保障安全性而在每个服务上都实现鉴权，这不但会带来代码冗余，而且每个微服务的演进也会受到严重影响。因此，在微服务的实践中，通过微服务网关实现对外服务集中管控成了必然选择。服务网关还具备授权、监控、负载均衡、缓存、静态响应处理等功能。
3.全链路日志系统
因为一个请求的处理可能会跨越多个节点的不同服务，服务出现异常后，在分布式系统中很难定位。因此，对服务的调用链跟踪分析也是实现微服务架构的必然选择。全链路日志系统除了提供日志汇集
试读结束[说明：试读内容隐藏了图片]