标签：数字化 实践 偏狭 架构 业务 技术 集中式 堆栈 分布式

经常在机场穿行的人们，很难注意不到铺天盖地的云计算广告牌。尤其是近几年阿里云的一系列广告创意相当霸气，大肆宣称“超过第二名至第十名规模总和”。我素来对于各种大词不感冒，反倒是广告里一行小字引发了关注：“数字化转型专家”。

过去数年间，在“互联网+”的本土语系中，数字化转型其实是一个比较夹生的表达方式。虽然“数字化”对这一进程本质的揭示更为深刻和普适，但不可否认的是，以“互联网”为前缀的表达方式在逆袭正劲的风口，具有更高的市场辨识度。

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

以金融科技（FINTECH）为例，今天在这个领域里的玩家，既有过去的所谓颠覆者纷纷从2C走向2B，也有传统银行突破体制格局，主动向市场输出科技能力。近来坊间还多有FINTECH和TECHFIN的概念纷争，其本质无非是携带着不同基因的参与者，共同汇入了一场金融数字化的进化之旅。强调TECH或者FIN也许并不重要，有资格活着参与进化的意义要远远大于技术性的炮制概念化差异。

如果以数字化转型甚至重塑的视角，去打量传统企业的主要实践，至少可以看到三个主要的方向。一、求差异，以数字化手段重构客户体验。二、谋格局，在数字化建设过程中创造新的业务模式，以满足（可数字化的）业务能力或者资产更灵活地在广义的业务生态中实现交付，乃至变现。三、孵创新，在企业内部通过机制，培育、孵化业务和技术的“杀手锏”。当然，天底下本没有什么新鲜事儿。对于企业来讲真正困难的并不是找到一招鲜的法宝，而是深刻基于自己的传统和现状，找出一条循序渐进的进化道路。我们可以认为这是一种“整合性”的创新能力。如果悖离自己的业务和技术的传统和现状，以突变、割裂的方式妄谈创新，往往只会为实践领域制造更多二元对峙的概念和文化冲突。毕竟“基因突变”和“天上掉馅饼”一样，都是极小概率事件。

而无论在哪个方向上去践行数字化转型，经历过这一波市场的洗礼，大多数企业对于“场景”都有了更加深刻的认知和感受。场景作为流量变现的关键，成为了事实上验证业务和技术的标准。这种共识使得人们比以往更加关注垂直的业务场景落地。“小而美”的垂直实践比“高大上”的平台构想要更加谨慎而务实。

以银行为例，处于业务敏感前沿的分行或业务部门近年来涌现出越来越多颗粒度不大，但是时效性比较迫切的数字化业务场景需求。这些业务场景往往具备较强的地域性、行业性甚至季节性，在业务运营模式上也具备较大的灵活自主性。在这种格局之下，全局性的横向平台如何去适应活跃、丰富的垂直创新，应该说是一个关键问题。

近年来，包括银行在内的众多企业科技部门纷纷热衷于PaaS或者原生云应用平台的建设。在银监会关于“十三五”规划的相关指导意见中，也特别强调要加大互联网类应用云化的力度。这些横向的平台构建如果仅仅是关起门来自己玩架构和技术，或者为云而云的搞应用移植、平台替换，可能很难找到业务和技术良性互动的关键点。

解决数字化业务的场景性诉求，可能恰恰是这类新平台的适用领域。在近几年的实践中，随着开源以及所谓分布式架构理念的普及，一个新的数字化技术堆栈正在发展成形。而PaaS或者原生云应用平台的兴起进一步驱动了应用架构的变迁，在实践上大大丰富了这个技术堆栈的内涵。从应用架构的角度，基于原生云的12要素架构原则及其大量设计模式得到了更为广泛的采纳。其架构的核心诉求是速度（唯快不破）、安全（容错）、扩展（弹性）。在开源社区，这样的应用设计理念得到了许多开源组件和框架的支持。而微服务架构理念的流行进一步为这些实践推波助澜。从技术架构的角度，容器与大规模容器集群、编排技术的广泛采纳与原生云应用架构可以说是天作之合。此外，随着容器作为应用和服务的标准分发/交付单元，dev和Ops终于可以被无缝的贯穿。由此，从开发交付的角度，devOps的采纳在技术上消除了壁垒。并进一步在文化和组织上提出了新的要求和挑战，如何在传统横向的组织边界中（如传统企业一部三中心的科技格局）去实现垂直业务场景的自治式演进。而这也正是微服务理念的核心精髓。此外，在这个新的技术堆栈中，大规模基于分析的运维与基于开源的支持生态也都提出了新的挑战和要求。

在这个新兴的技术堆栈中，各种不同的实践并没有严格的时序先后依赖，而是保持着一种内在的逻辑关联各自展开，就像一幅拼图从碎片中逐渐呈现出全景一样。还记得两三年前跟一些大型客户交流时，说微服务和容器就是天作之合。当时大家的反应还是持保守和观望态度。而到了今天，我们是不是可以更加清晰的表述一个更大的图景：数字化业务丰富的场景诉求正在驱动一个新的企业数字化技术堆栈不断成熟。数字化场景、微服务、容器、devOps，这些元素都是天作之合。都是同一个进化过程在不同面向上的表达，其内在是彼此暗合、高度一致的。

从企业实践的角度，不管用什么名称，从哪个角度去定义，最关键的就是找到适合自己的抓手，并且始终在发展过程中保持全局观，以堆栈化的整体视图来设计路线图，并根据实践不断持续更新。毕竟，这个领域的实践，以及这个堆栈的发展，并不是以一种自上而下的方式铺陈，而是基于社区、基于实践的进化。回到三十年前的那本名著《人月神话》的核心观点，仍然没有银弹（No Silver Bullet）！没有一招鲜,没有万能药！有的就是脚踏实地参与进化的历程。这个历程就是企业在传统经典技术堆栈的基础之上继续演进，生长出新的“数字化双翼”。

然而，在新的数字化堆栈的发展过程中，我们也特别注意到了一些流行的二元对峙的偏狭观念，其流弊之广、危害之深值得实践者们高度关注。

……“不把所有鸡蛋放到一个篮子里”成为了所谓分布式阵营的一个貌似绝对正确的理念和旗号。在实践中，可以看到不少过于僵化和教条的做法，……问题已经超越了鸡蛋和篮子的关系。而是要不要把蛋黄和蛋清放到一个蛋壳里！未来运维和业务将不得不为这些麻烦而买单。……

1） 集中式与分布式的对立

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

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

标签：数字化,实践,偏狭,架构,业务,技术,集中式,堆栈,分布式
来源： https://blog.51cto.com/u_15127582/2756858

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。