分布式微服务融合技术架构趋势解读

1、 分布式微服务融合技术架构趋势解读 导读随着全球数字化浪潮的洗礼，新一代的颠覆者们凭借着业务与技术双驱的洪荒之力为业界树立了新的“最佳实践”和“参考架构”。传统行业以及经典的企业IT领域在过去数年间历经了持续的颠簸。如何在保持自身核心基因的前提下，增益其过往之所不能，这已经成为了IT领导们亟待解决的问题。这场纷纷扰扰的架构之争，并非一场简单的遭遇战，而恰恰是企业IT在数字化背景下持续演进的表征。在这个从分庭对立走向兼容并蓄的历史进程中，实践者们需要更加深刻与快速的实践、反思能力，去辨识、扬弃一些流毒甚广的肤浅观念，以实践去参与进化，见证融合。本文原题：中道为正、无问西东数字化浪潮下的架构融合浅

2、谈经过了这些年商业与技术的“颠覆”乱局后，人们至少都学会了“以彼之道还施彼身”，在挨打和混战中学会了打架。有资格活着参与进化的意义要远远大于技术性的炮制概念化差异。经常在机场穿行的人们，很难注意不到铺天盖地的云计算广告牌。尤其是近几年阿里云的一系列广告创意相当霸气，大肆宣称“超过第二名至第十名规模总和”。我素来对于各种大词不感冒，反倒是广告里一行小字引发了关注：“数字化转型专家”。过去数年间，在“互联网+”的本土语系中，数字化转型其实是一个比较夹生的表达方式。虽然“数字化”对这一进程本质的揭示更为深刻和普适，但不可否认的是，以“互联网”为前缀的表达方式在逆袭正劲的风口，具有更高的市场辨识度。在

3、一个领域中，话语构建的水平往往也表征了其本身的成熟与进化程度。更多从业者们对于“数字化转型”语系的普遍采纳，除了表明近几年互联网与传统IT企业基因混杂、彼此融合的特征，也表明了企业市场在历经颠覆、迷茫、跟风、实践之后，愈加清朗地辨明了自己的主要矛盾与核心诉求。IBM商业价值研究院近来发表了一系列关于“数字化重塑”（数字化转型的进阶）和“传统企业逆袭”的研究报告。虽然我们并不敢说这预示着传统企业数字化复苏的春天就要到来了，但是经过了这些年商业与技术的“颠覆”乱局后，人们至少都学会了“以彼之道还施彼身”，在挨打和混战中学会了打架。以金融科技（FINTECH）为例，今天在这个领域里的玩家，既有过去的

4、所谓颠覆者纷纷从2C走向2B，也有传统银行突破体制格局，主动向市场输出科技能力。近来坊间还多有FINTECH和TECHFIN的概念纷争，其本质无非是携带着不同基因的参与者，共同汇入了一场金融数字化的进化之旅。强调TECH或者FIN也许并不重要，有资格活着参与进化的意义要远远大于技术性的炮制概念化差异。如果以数字化转型甚至重塑的视角，去打量传统企业的主要实践，至少可以看到三个主要的方向。一、求差异，以数字化手段重构客户体验。二、谋格局，在数字化建设过程中创造新的业务模式，以满足（可数字化的）业务能力或者资产更灵活地在广义的业务生态中实现交付，乃至变现。三、孵创新，在企业内部通过机制，培育、孵化业

5、务和技术的“杀手锏”。当然，天底下本没有什么新鲜事儿。对于企业来讲真正困难的并不是找到一招鲜的法宝，而是深刻基于自己的传统和现状，找出一条循序渐进的进化道路。我们可以认为这是一种“整合性”的创新能力。如果悖离自己的业务和技术的传统和现状，以突变、割裂的方式妄谈创新，往往只会为实践领域制造更多二元对峙的概念和文化冲突。毕竟“基因突变”和“天上掉馅饼”一样，都是极小概率事件。而无论在哪个方向上去践行数字化转型，经历过这一波市场的洗礼，大多数企业对于“场景”都有了更加深刻的认知和感受。场景作为流量变现的关键，成为了事实上验证业务和技术的标准。这种共识使得人们比以往更加关注垂直的业务场景落地。“小而美

6、”的垂直实践比“高大上”的平台构想要更加谨慎而务实。以银行为例，处于业务敏感前沿的分行或业务部门近年来涌现出越来越多颗粒度不大，但是时效性比较迫切的数字化业务场景需求。这些业务场景往往具备较强的地域性、行业性甚至季节性，在业务运营模式上也具备较大的灵活自主性。在这种格局之下，全局性的横向平台如何去适应活跃、丰富的垂直创新，应该说是一个关键问题。近年来，包括银行在内的众多企业科技部门纷纷热衷于PaaS或者原生云应用平台的建设。在银监会关于“十三五”规划的相关指导意见中，也特别强调要加大互联网类应用云化的力度。这些横向的平台构建如果仅仅是关起门来自己玩架构和技术，或者为云而云的搞应用移植、平台替换

7、，可能很难找到业务和技术良性互动的关键点。解决数字化业务的场景性诉求，可能恰恰是这类新平台的适用领域。在近几年的实践中，随着开源以及所谓分布式架构理念的普及，一个新的数字化技术堆栈正在发展成形。而PaaS或者原生云应用平台的兴起进一步驱动了应用架构的变迁，在实践上大大丰富了这个技术堆栈的内涵。从应用架构的角度，基于原生云的12要素架构原则及其大量设计模式得到了更为广泛的采纳。其架构的核心诉求是速度（唯快不破）、安全（容错）、扩展（弹性）。在开源社区，这样的应用设计理念得到了许多开源组件和框架的支持。而微服务架构理念的流行进一步为这些实践推波助澜。从技术架构的角度，容器与大规模容器集群、编排技术

8、的广泛采纳与原生云应用架构可以说是天作之合。此外，随着容器作为应用和服务的标准分发/交付单元，dev和Ops终于可以被无缝的贯穿。由此，从开发交付的角度，devOps的采纳在技术上消除了壁垒。并进一步在文化和组织上提出了新的要求和挑战，如何在传统横向的组织边界中（如传统企业一部三中心的科技格局）去实现垂直业务场景的自治式演进。而这也正是微服务理念的核心精髓。此外，在这个新的技术堆栈中，大规模基于分析的运维与基于开源的支持生态也都提出了新的挑战和要求。在这个新兴的技术堆栈中，各种不同的实践并没有严格的时序先后依赖，而是保持着一种内在的逻辑关联各自展开，就像一幅拼图从碎片中逐渐呈现出全景一样。还记

9、得两三年前跟一些大型客户交流时，说微服务和容器就是天作之合。当时大家的反应还是持保守和观望态度。而到了今天，我们是不是可以更加清晰的表述一个更大的图景：数字化业务丰富的场景诉求正在驱动一个新的企业数字化技术堆栈不断成熟。数字化场景、微服务、容器、devOps，这些元素都是天作之合。都是同一个进化过程在不同面向上的表达，其内在是彼此暗合、高度一致的。从企业实践的角度，不管用什么名称，从哪个角度去定义，最关键的就是找到适合自己的抓手，并且始终在发展过程中保持全局观，以堆栈化的整体视图来设计路线图，并根据实践不断持续更新。毕竟，这个领域的实践，以及这个堆栈的发展，并不是以一种自上而下的方式铺陈，而是

10、基于社区、基于实践的进化。回到三十年前的那本名著人月神话的核心观点，仍然没有银弹（No Silver Bullet）！没有一招鲜,没有万能药！有的就是脚踏实地参与进化的历程。这个历程就是企业在传统经典技术堆栈的基础之上继续演进，生长出新的“数字化双翼”。然而，在新的数字化堆栈的发展过程中，我们也特别注意到了一些流行的二元对峙的偏狭观念，其流弊之广、危害之深值得实践者们高度关注。“不把所有鸡蛋放到一个篮子里”成为了所谓分布式阵营的一个貌似绝对正确的理念和旗号。在实践中，可以看到不少过于僵化和教条的做法，问题已经超越了鸡蛋和篮子的关系。而是要不要把蛋黄和蛋清放到一个蛋壳里！未来运维和业务将不得不为

11、这些麻烦而买单。1） 集中式与分布式的对立集中或者分布本身是两种处理问题的方式或者风格，就像是同步与异步一样。但是市场上的一些流行理念却活生生将集中与分布划分成了两个彼此对峙的阵营。在所谓的集中式阵营中，如果一定要找一个靶子，那么基于IBM Z（俗称主机）的技术堆栈可以算得上“众矢之的”的集中式源头。主机的技术堆栈在半个世纪前开启了以服务器为核心的计算时代，发展和成熟于业务、数据大集中处理时代。其一直立足于关键事务处理的企业级计算。作为一个发展最为成熟的通用商业计算体系，不难发现其技术堆栈秉持的一些关键性假设和原则：以成熟、领先的贯穿全堆栈的系统优势，来为用户换取在开发交付和运行维护上更大的专

12、注性。这其实是多年来流行在企业级计算领域的一个重要原则Separation of Concerns（关注分离、专于其事）。经典的企业IT组织格局以及技术支持生态也都是基于这样的基本原型逐渐演化形成的。在成熟的主机用户身上，我们能够看到一些典型的特征。比如，从系统角度：精简的系统部署、充裕的扩展能力、连续的业务可用、集约的运维规模。从开发角度：专注于业务的开发模式，更好的架构包容性（有容乃大?）。（图示：经典的基于主机的技术堆栈示意）不难发现，这个经典的技术堆栈要达到的首要目标并不是所谓集中，而是打造一个最高品质的通用商业计算体系。换言之，就是通过系统化的技术手段保障其核心价值的可复制性和普遍性

13、，而不依赖于对运维或应用等外部因素提出过多特质化的要求。当然，在多年的实践中，运维和应用也一定会根据系统的特点（优势以及短板）而发展出具有独特性的资产。可以说这几年主机用户一系列以减少消耗为导向的优化举措也是非常有益的探索。但是我们应该认识到，一个成熟的商业技术堆栈与兴起于互联网超级玩家的技术堆栈在发展模式上的确存在差异。超级互联网玩家追求对于技术全栈尽可能的自主掌控是基于其超级庞大的业务和科技体量、爆发式的发展增速，以及业务和科技融为一体的企业基因。商业系统的运作则是基于契约式。说白了就是，用经济手段交换能力，用合约手段保障承诺。当然，今天国内互联网巨头纷纷开始以科技输出进入这个领域，都面临

14、着从“自食狗粮”向商业契约化的过渡和转化。这一点迟早会把不同基因的参与者拉回到同一个角斗场。其次，就算回到集中与分布的技术纷争。我认为也很难完全把一个技术体系简单归为集中或者分布。很多人可能没有认识到，基于主机的传统交易中间件CICS本身就是为分布式服务而构建。CICS的缩写据说可以解释为CICS IS CONTAINER SERVICE，这并非笑谈！作为分布式服务所需要的容器化运行环境、远程调用框架、服务的注册、发现、路由、负载均衡等等能力在这个技术体系内都有对应的经典实现方式。至于在物理部署模式上是采用水平扩展、垂直扩展或者混合模式，更多的是从性能的优化、运维的效率、扩展的空间等多种角度来

15、综合考虑。反观近年来市场上流行的分布式架构实践，其实质往往无外乎是开源技术的采纳，应用的服务化（甚至微服务化）、以及去状态或者无状态化，严格一致性的妥协，广泛的异步式处理，再加上数据的业务性或者技术性分散。在过往全球互联网巨头的实践中，这些手段的运用都是有其上下文和条件的。但是如果将之作为一个教条的概念，甚至赋予新一代“银弹”的期望，不求甚解甚至囫囵吞枣，也会带来负面而深远的影响。“不把所有鸡蛋放到一个篮子里”成为了所谓分布式阵营的一个貌似绝对正确的理念和旗号。在实践中，可以看到不少过于僵化和教条的做法，比如在没有扩展性瓶颈的前提下单纯用技术性手段强行分拆数据。我认为一些问题已经超越了鸡蛋和篮

16、子的关系。而是要不要把蛋黄和蛋清放到一个蛋壳里！未来运维和业务将不得不为这些麻烦而买单。套用流行的佛系用语，“是诸法空相，不生不灭，不垢不净，不增不减，不集中不分布，不同步不异步。”实践者需要睁开智慧的架构之眼，以己之眼明辨是非，而不人云亦云。怎么加班交付都不够敏捷，怎么解耦应用都还是一团乱麻，怎么监控生产都还是如履薄冰。与微服务相对的巨石架构随即躺枪成为了万恶之源，如过街老鼠人人喊打。2） 微服务与巨石的对立随着微服务架构的迅速蹿红，这颗新的“银弹”又给市场注入了巨大的想象力。人们在传统的交付和运维苦海中挣扎着，怎么加班交付都不够敏捷，怎么解耦应用都还是一团乱麻，怎么监控生产都还是如履薄冰。

17、与微服务相对的巨石架构随即躺枪成为了万恶之源，如过街老鼠人人喊打。然而如果我们稍微研究一下微服务架构的历史沿革和实质，会发现其关键强调的是一种架构和交付的文化，“微”的目的是为了服务能够独立、自治的垂直演进。记得曾经有一种非常有趣的说法，单个微服务的设计、开发、测试和运维的所有人加在一起吃饭，只需要两张批萨就够了，这是就是著名的“Two pizza team”原则。在这种模式之下，devOps几乎毫无例外的是刚需。然而如果仅仅是教条地将微服务作为一种普遍性准则，不分场合，生搬硬套，同样会遭遇尴尬。在实践中，人们往往最多的问题就是，找不到传统应用重构为微服务的合适场景。而且这种架构和交付方式对于

18、经典的组织结构和文化也造成了极大的冲击。如何跳出传统的红海（苦海）的束缚，找到一片业务和架构的蓝海，成为了很多实践者关心的话题。回到“骨感”的现实中，对于传统企业而言，微服务的采纳有可能并不是一个最急迫的核心问题。而且我们相信经过这么多年应用的治理，在一个有一定水准的企业内，巨石架构的弊端也没有外界想象那么严重。但是在实践中，必须承认服务化治理本身的确是一个既急迫又长期的过程，自SOA时代以来落下的功课早晚是要交上的。“高内聚、低耦合”在什么时代都是服务的黄金法则。（图示：服务治理的急迫性，图片摘自断舍离）我们在前面曾经提到过，主机架构对于应用有着更大的包容性。这一点在服务治理的历程中是可以得

19、到印证的。记得十几年前，IBM就建议主机CICS的用户在部署应用时，尽量将长交易、短交易，不同业务目标的应用分配部署到不同群组的CICS容器（region）中去。这样可以利用系统对于混杂工作负载的调度管理能力，充分地利用系统资源。然而这么多年过去了，大多数国内银行的主机用户仍然利用着系统尚充裕的垂直扩展性，保持着近乎极简的部署模式。不少用户不分或者极少划分业务群组，在每个CICS容器中都部署近乎全量的应用，并通过外围路由来区分不同类型的访问请求。这样的做法从积极的意义上，可以认为充分利用了系统架构的优势，简化了开发、部署和运维，并通过架构的包容性为服务治理争取了时间。然而，人们也应该意识到，这

20、样的架构如果平移到另外一个所谓的分布式应用平台，其结果将是灾难的。毋庸置疑，服务的治理是一项长治久安的百年大计。从这个意义上，微服务本身并不是解决这个问题的“一招鲜”。微服务或者巨石作为两种不同风格的架构，从长远来讲是可以共生共存的，更何况在二者之间还有广阔的地带。关键是找到彼此最合适的领域。我认为在垂直的数字化场景这个领域中，可以尝试在新的数字化堆栈中开展微服务的尝试。当然这种尝试也需要找到合适的抓手，不可僵化套用。比如，在一些大型企业的实践中，先通过无状态的弹性应用去推动新技术堆栈的发展，有可能是更加符合现实诉求的。混合、双速或者融合的技术堆栈格局，恰恰是在快速演进的业务格局中一种“中道”

21、式的自然过程。而历史的演进，往往是从二元对峙的谬误中，开启融合之路。最后，通过以上的探讨，让我们尝试抛出一些架构融合的观察和建议。在传统经典的技术堆栈（如基于IBM Z）之外，新的技术堆栈（所谓数字化双翼）正在成型，并迅速演变。这些技术堆栈之间并不能简单用商业/开源，集中/分布，传统/颠覆来进行概念化二元对峙的区分。在各自的发展路径上，甚至是可以彼此参照，互相包容，共同进化的。（图示：以主机用户为例的架构融合、双技术堆栈示意）以采纳了经典主机作为核心的企业为例，在实践架构融合的进程中，我们建议：以Restful API的方式，将主机堆栈的应用和数据资产融入到一个原生的API环境中，提供最大的灵活性。开辟全新的纯API的主机高速接入/调出通道，实现两个技术堆栈的高架合龙。继续推进服务化改造和优化工作。推动新的企业数字化堆栈建设，找到业务和应用诉求的突破口。顶层布局，总体部署。避免架构和技术堆栈的孤岛。共同推动商务与技术的协同进化。在本文开篇时，我们曾经简单谈到了在数字化转型的浪潮中，传统企业的复苏甚至逆袭。随着数字化服务生态的飞速演进，大家也必须看清一些事实。作为数字化生态和流量经济