数字化浪潮下的架构融合浅谈

集中或者分布本身是两种处理问题的方式或者风格，就像是同步与异步一样。但是市场上的一些流行理念却活生生将集中与分布划分成了两个彼此对峙的阵营。在所谓的集中式阵营中，如果一定要找一个靶子，那么基于IBM Z(俗称主机)的技术堆栈可以算得上“众矢之的”的集中式源头。

主机的技术堆栈在半个世纪前开启了以服务器为核心的计算时代，发展和成熟于业务、数据大集中处理时代。其一直立足于关键事务处理的企业级计算。作为一个发展最为成熟的通用商业计算体系，不难发现其技术堆栈秉持的一些关键性假设和原则：以成熟、领先的贯穿全堆栈的系统优势，来为用户换取在开发交付和运行维护上更大的专注性。这其实是多年来流行在企业级计算领域的一个重要原则–Separation of Concerns(关注分离、专于其事)。经典的企业IT组织格局以及技术支持生态也都是基于这样的基本原型逐渐演化形成的。在成熟的主机用户身上，我们能够看到一些典型的特征。比如，从系统角度：精简的系统部署、充裕的扩展能力、连续的业务可用、集约的运维规模。从开发角度：专注于业务的开发模式，更好的架构包容性(有容乃大)。

不难发现，这个经典的技术堆栈要达到的首要目标并不是所谓集中，而是打造一个最高品质的通用商业计算体系。换言之，就是通过系统化的技术手段保障其核心价值的可复制性和普遍性，而不依赖于对运维或应用等外部因素提出过多特质化的要求。当然，在多年的实践中，运维和应用也一定会根据系统的特点(优势以及短板)而发展出具有独特性的资产。可以说这几年主机用户一系列以减少消耗为导向的优化举措也是非常有益的探索。但是我们应该认识到，一个成熟的商业技术堆栈与兴起于互联网超级玩家的技术堆栈在发展模式上的确存在差异。超级互联网玩家追求对于技术全栈尽可能的自主掌控是基于其超级庞大的业务和科技体量、爆发式的发展增速，以及业务和科技融为一体的企业基因。商业系统的运作则是基于契约式。说白了就是，用经济手段交换能力，用合约手段保障承诺。当然，今天国内互联网巨头纷纷开始以科技输出进入这个领域，都面临着从“自食狗粮”向商业契约化的过渡和转化。这一点迟早会把不同基因的参与者拉回到同一个角斗场。

其次，就算回到集中与分布的技术纷争。我认为也很难完全把一个技术体系简单归为集中或者分布。很多人可能没有认识到，基于主机的传统交易中间件CICS本身就是为分布式服务而构建。CICS的缩写据说可以解释为CICS IS CONTAINER SERVICE，这并非笑谈!作为分布式服务所需要的容器化运行环境、远程调用框架、服务的注册、发现、路由、负载均衡等等能力在这个技术体系内都有对应的经典实现方式。至于在物理部署模式上是采用水平扩展、垂直扩展或者混合模式，更多的是从性能的优化、运维的效率、扩展的空间等多种角度来综合考虑。反观近年来市场上流行的分布式架构实践，其实质往往无外乎是开源技术的采纳，应用的服务化(甚至微服务化)、以及去状态或者无状态化，严格一致性的妥协，广泛的异步式处理，再加上数据的业务性或者技术性分散。在过往全球互联网巨头的实践中，这些手段的运用都是有其上下文和条件的。但是如果将之作为一个教条的概念，甚至赋予新一代“银弹”的期望，不求甚解甚至囫囵吞枣，也会带来负面而深远的影响。

“不把所有鸡蛋放到一个篮子里”成为了所谓分布式阵营的一个貌似绝对正确的理念和旗号。在实践中，可以看到不少过于僵化和教条的做法，比如在没有扩展性瓶颈的前提下单纯用技术性手段强行分拆数据。我认为一些问题已经超越了鸡蛋和篮子的关系。而是要不要把蛋黄和蛋清放到一个蛋壳里!未来运维和业务将不得不为这些麻烦而买单。

套用流行的佛系用语，“是诸法空相，不生不灭，不垢不净，不增不减，不集中不分布，不同步不异步。”实践者需要睁开智慧的架构之眼，以己之眼明辨是非，而不人云亦云。

2)微服务与巨石的对立

随着微服务架构的迅速蹿红，这颗新的“银弹”又给市场注入了巨大的想象力。人们在传统的交付和运维苦海中挣扎着，怎么加班交付都不够敏捷，怎么解耦应用都还是一团乱麻，怎么监控生产都还是如履薄冰。与微服务相对的巨石架构随即躺枪成为了万恶之源，如过街老鼠人人喊打。

然而如果我们稍微研究一下微服务架构的历史沿革和实质，会发现其关键强调的是一种架构和交付的文化，“微”的目的是为了服务能够独立、自治的垂直演进。记得曾经有一种非常有趣的说法，单个微服务的设计、开发、测试和运维的所有人加在一起吃饭，只需要两张批萨就够了，这是就是著名的“Two pizza team”原则。在这种模式之下，devOps几乎毫无例外的是刚需。然而如果仅仅是教条地将微服务作为一种普遍性准则，不分场合，生搬硬套，同样会遭遇尴尬。在实践中，人们往往最多的问题就是，找不到传统应用重构为微服务的合适场景。而且这种架构和交付方式对于经典的组织结构和文化也造成了极大的冲击。如何跳出传统的红海(苦海)的束缚，找到一片业务和架构的蓝海，成为了很多实践者关心的话题。

回到“骨感”的现实中，对于传统企业而言，微服务的采纳有可能并不是一个最急迫的核心问题。而且我们相信经过这么多年应用的治理，在一个有一定水准的企业内，巨石架构的弊端也没有外界想象那么严重。但是在实践中，必须承认服务化治理本身的确是一个既急迫又长期的过程，自SOA时代以来落下的功课早晚是要交上的。“高内聚、低耦合”在什么时代都是服务的黄金法则。

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

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!