阿里妹进行导读, 在业务发展既纷繁且杂乱的情形之下, 变化已然变成了仅有的不变之物, 怎么去保障基础设施具备安全跟高可用性, 与此同时还能够给予高效的创新支持呢? 如今, 身为阿里副总裁以及业务平台事业部负责人的玄难, 把阿里巴巴业务平台建设跟个人多年大型软件设计经验相结合, 归纳成了几点思考, 期望能够对大家的软件架构设计给出启发。
玄难
阿里副总裁
业务平台事业部掌门人
要特别加以说明的是, 在本文里面所提及的软件, 全部都是用来指代面向最终用户的、偏向于业务方面的软件, 此处一概不涵盖操作系统、中间件等系统软件。
1、软件发展的几个阶段
在软件形态出现变化之际, 往昔极为高效的系统架构以及组织形态遭遇了全方位的挑战。这是由于我们身处的环境已然从量变迈向质变, 冲破了临界点, 进而产生了本质上的差异。
阿里就是此进程中的关键实例, 于往昔仅是单一电商事务, 迄已演进成复杂化的庞大经济体，不复存在拥有稳定性的业务界限, 那些蒸蒸日上的业务难具预先可推断性, 极具典型特征得是。
自往昔的一个淘宝发展而来, 现今已演变为几十多个事业部以及公司, 其中涵盖新零售、云计算、文娱健康等几百种业务, 且仍在持续疾速演进。
最初是一个Denali系统, 此后经分布式架构不断演变, 最终形成了上万个系统的群落, 这其中, 各类业务逻辑相互交织, 且贯穿多个系统, 实在言辞难表, 又思绪繁杂。
原来几十人的协同, 变成了几万人的协同, 每个人好似身处原始热带雨林, 不晓得业务的全面情况, 如同盲人摸象一般。
以往可以停机发布, 如今成为不可中断、持续进化的社会基础设施, 不但需系统稳定性, 更得有业务连续性。怎样保障此基础设施的安全以及高可用性, 还要给业务方提供高效且无阻碍的创新支持, 这便是我们必须解决的核心问题。
针对这些问题，我们对软件设计产生了几点基本思考。
2、传统软件设计：外延的确定性
咱们身为程序员, 都清楚这么回事: 想要软件能够契合预期, 就需要具备确定性。对于程序设计而言, 不确定性可是具有致命性的。因而我们常常会听闻抱怨声“需求又发生变化了”, 在网上有许多段子都是说程序员去指责业务方以及产品经理持续不断地变更需求的。
在“工具和信息化”之际, 软件从本质上来说, 是运用计算机软件去模拟原本的人工工作, 达成电子化状态, 所以它具备一个典型特性, 那就是业务领域、软件职责以及功能边界都相对清晰。故而, 最为经典的软件工程理论乃是瀑布模型, 具体包括收集需求、绘制UserCase、明确功能集合、进行模型抽象、开展概要设计、实施详细设计、展开编码、开展单元测试、实施集成测试、进行用户测试、上线运行。随后投入到下一个版本的迭代之中。传统的软件开发大多为此种模式。这种模式特别强调文档质量和变更的全流程一致。
互联网服务时代, 计算机软件达成了靠人力无法做到的能力, 给人类社会供给了诸多全新服务能力。我们承袭了传统软件工程理论, 还做了适度改进。为缩短版本迭代时间, 更快验证产品想法获取用户, 多数团队采用敏捷模型。本质上是将需求批发模式转变为零售模式。此模式最大益处是对产品需求快速响应, 可致命的是每次敏捷多数时候在持续打补丁, 软件架构迅速腐化。不到两年, 敏捷其实变成了蜗牛。熬过两年, 若忍受不了, 便进行重构, 然而那所谓的重构实际上是彻底推倒重新做起, 在这样的模式情形下面, 几乎是不存在可用的文档了。
有一个基本假设存在于前面那, 两个阶段的软件, 都已存在设计理论上, 这个假设就是软件边界是已然有确定性的, 我们凭借归纳总结以及做出适度的预测, 还要去避免出现过度设计这种状况, 以此来进行模型抽象这一行为。借助模型抽象这个行为, 我们设计了各类可配置性, 以此来实现快速接入需求, 进而提升效率, 而这也就是我们平常经常会说到的产品化。凭借接口设计以及模块化设计, 来开展组织分工协作。依靠系统架构的开放性, 来应对那些不能配置过程里出现的变化。变化通常是来自两个方面的:
首先存在用户量的增长情况, 一般是运用分布式予以解决, 即分布式数据库, 分布式缓存, 分布式服务, 多机房多单元, CDN等等, 在该方面阿里巴巴应当算得上是做得极其出色的, 从五彩石起始一直到现在, 阿里巴巴的架构大体上都是这一指导性思想的着陆施行以及优化完备, 并且依旧是应对量快速增长的精巧办法。
从业务功能发生变化的第二个方面来看, 也就是我们平常所讲的系统可扩展性, 借助传统数据库的大字段或者NoSQL, 采用“元数据+K-V存储”这种方式去应对数据信息的不确定性；凭借流程引擎来达成工作流程的快速响应；利用规则引擎替代程序当中大量的If-Else, 借助界面配置达成规则的变化；依靠UI组件化, 搭配UI的编辑器快速对用户界面的变化作出调整；通过插件技术把容易发生变化, 同时相对复杂的逻辑从主流程里剥离出来予以扩展。我们去看目前比较的套装优秀软件都大致如此。
一直到现在为止, 我们所进行的软件研发, 全部都是针对一个具有确定性的问题展开的, 这就好比是一个圆圈, 它是存在需求边界的, 我们从四周朝着内部聚拢, 去做抽离具象的工作, 也就是我们所说的业务抽象或者建模；它就如同我们居住的房子, 是被四个边角处的承重墙划分清楚了边界的, 房子里面的装修能够依据房屋主人的喜好以及不同阶段的诉求进行重新构建, 然而却没办法朝着外部进行扩展延伸；它所具备的特性是框架结构, 业务领域模型呈现出经过抽象、组件化、形成版本以及外延向着内部收敛的状态。
3、思考角度的变化：内核的确定性
随着移动互联网的发展, 随着IOT的发展, 随着人工智能的发展, 软件成了社会的基础设施, 我们每个人无一不被软件紧紧地掌控着, 整日黏附在手机与电脑之上。人实际上是以终端形式接入软件网络。社会形态不存在边界, 处于持续变化之中, 且无法预测。阿里当下的业务同样不存在确定性边界, 不清楚明天会变为何种模样, 它不是版本化的, 而是在持续不断地生长与变异。就是不存在确定性的软件外延。要是没有确定性的外延, 然而软件的运行却需要确定性, 那我们就唯有去寻觅确定性的内核。
对于该怎么去理解那种变化, 我们能够借助机器学习的发展来作类比。传统的机器学习拥有众多算法模型, 有线性回归、决策树、随机森林算法、逻辑回归、SVM、朴素贝叶斯、K最近邻算法、K均值算法等这么多。我们要是想要解决, 那首先得先要试着去分析问题领域, 这样才能够选择相匹配的算法模型, 进而才可以获得好的结果。要是属于一个非线性问题, 然而却错误地选用了线性模型, 那就根本拿不到结果了。这样一种解决问题的思路, 就是得先去寻觅一个具有确定性的问题边界, 然后才能够往内去寻找参数。但深度学习的解决思路存在着一个本质方面的变化, 并非去定义问题的领域范围, 而是仅仅定义稳定的结构, 比如BP神经网络, 它具备输入层, 有多个隐藏层以及输出层。要是我们将图像数据输入其中, 那么就能够构建起图像分类以及人脸识别的能力, 要是把语音输入进去, 便可以构建出语音识别的能力（当然实际情况并非表述得如此简易）。深度学习呈现出一种由内心向外在自我学习以及生长的态势。
软件工程碰到同样问题, 需从外沿确定性转至内核确定性。从逻辑推理角度讲, 传统软件工程以归纳法为主, 局部用演绎法, 而面对外延不确定性领域, 要找稳定内核基础，再以演绎法为主, 局部用归纳法。我们先找内核, 内核向外生长、变异, 原来的确定性是找外沿确定, 如今要找内核确定。原本是归纳法, 现在要演绎, 找出不变的, 如同人受基因控制那般。当然你也可以说这是一种跨业务领域的更高阶的抽象。
4、文档即代码
展望计算机的发展历程, 知晓软件研发效率的成长实质是填补现实世界与计算机二进制世界间的差距。起初是二进制编码, 然后接着变化为汇编, 继续延续到C语言, 后续又发展至面向对象的C++、JAVA。每一回获得提升都是运用人类更易领会的形式对现实世界做抽象的刻画, 接着借助一个编译程序毫无差别的转译为低位阶, 径直地直至计算机能够执行的二进制。每一回的变动全都促使软件研发效率以指数级速度增长, 与此同时让能够参与软件设计的人数也呈现指数增长, 为整个社会带来显著的进步。这份当中至关重要的最大功臣毫无置疑是编译器。有着最关键实质的核心资产是编译之前的源代码, 并非编译之后能够运行启动的二进制代码。鉴于编译之后的代码难以理解明白, 并且绝无有可能借助逆向工程复原出源代码。要是遗失了源代码, 基本上就已然丧失了所有的一切。
身处时下的业务范畴, 我们皆称自己从事业务, 像比如说业务平台宣称支持了淘宝、天猫、拍卖、盒马生鲜、天猫超市、飞猪机票、火车票等诸多业务达上百种。然而我们的代码里全然寻觅不到这些核心业务概念。我们都清楚电商最为核心的交易模式诸如担保交易、预售、团购、货到付款等同样不可能在代码中被找到。我们也不存在准确的文档去描述这些内容。这是传统的软件工程方法以及技术方面的局限所造成的。
在我们开展的工作进程里, 从需求分析着手, 到进行概要设计, 再到开展详细设计, 直至最终完成Java代码, 实际上这一整个流程就是将业务逻辑, 转移到计算机世界的一回编译历程。在此过程当中, 最为突出的问题在于, 并不是借助机器完成无差别编译, 反而是依靠人力来进行编译, 并且这个编译过程会因为不同的人, 出现显著的差异性。正是基于这种不确定性, 使得所有的设计文档, 随着时间不断地向前推移, 与实际运行着的代码之间, 产生了无法弥合的巨大鸿沟。如此一来, 一个业务系统的文档, 变得越来越没有实际用处, 进而也就导致越来越少的人愿意去撰写它了。倘若不能够达成文档即代码这样的目标, 那么我们便无法留存下真实且能够有效使用的文档。
要将设计与实现融合起来, 我们去观察自然世界, 所有的设计文档图纸实际上就是DNA, DNA在生命体的每个细胞里都有存在, DNA的传承就是生命的传承, 所有外化的文档最后都易于消失, 如同秦始皇一把火就把人类多年的沉淀与传承给毁掉了, 然而DNA内生物的本能传承一代又一代获得了传承与优化。
目标是, 不存在那种不依赖于可执行系统的独立文档, 所有的信息都包含于系统里, 只是借助一些工具予以可视化从而增强可读性这件事而已任何一方都绝非凭空存在的, 所有的信息都必然归属于一个业务单元, 属于一个业务对象。
5、面向功能的组件化设计到面向业务的对象化设计
我们所处的世界, 能够依据熵变化的趋向, 划分成呈现熵增状态的无机体部分, 以及体现为熵减走势的生命体部分。
无机体是依靠设计、图纸, 从顶部的层面开始, 一层一层地进行分解、细化进而开展设计工作, 随后组装形成的, 其典型的特性是通过标准组件化的设计与批量生产途径来达成协同以及提升效率的目的。
由内向外地生长以及变异着的, 是生命体。看上去呈组件态势, 然而因基因存在差异 , 实际上不同生命体不可替换 , 会引发排异反应。所有组成部分在基因操控下同步生长。生命体进行持续性的生长与变异。
由所有借助组件化构建而成的无机体, 倘若想要发生质变, 无一不是要推倒后重新再来, 就如同我们的城市始终在持续不断的拆迁进程里实现膨胀那般。又如我们的7号楼, 在其设计宣告结束之时, 便已然确定它仅能为6楼, 或许能够凭借冗余部分加盖到8楼, 然而要是增加至20楼, 它必定会走向崩溃。若要盖到20层, 那就只能将其推倒重新建造。
于是, 按照抽象归纳而言, 那种进行组件化设计的软件系统, 跟着业务不断发展，所产生的补丁变得越发多起来, 运行几年之后就会遭遇被推倒重新来过的情况, 这便是它注定的命运。
个别有机体的复杂度存在限度, 依靠群体协作打造庞大规模与力量。群体历经单体变异与自然选择推动进化, 生命进化无法预知, 类似父亲对儿子成长及未来难以预料。
目前, 我们的业务系统是由组件化系统构成的, 像购物车、店铺、详情、库存、交易、营销、资金、支付、结算、财务体系等。所有业务的达成, 实际上是通过数据在这些组件系统里流动方可实现。在这个运行系统当中, 我们看不到天猫、淘宝、盒马、天猫超市、担保交易、预售、团购这些我们耳熟能详的事物。它们都体现在一个个零散的数据字段以及IfElse里面。
就我们所采取的设计思路而言, 乃是要回归至业务自身的本质, 借助对象化方面去实施操作, 以此使得处于运作过程里的业务能够拥有可生长、可传承以及可变异的特性。最基础的那部分思维是: 置于整体层面之中的系统, 其根基所在乃是业务。你将会目睹到一个切实存在的类别, 该类别被称作淘宝、天猫, 它们存在着一个名为市场的父类, 而天猫超市堪称是独立存在的类别, 它是天猫的子类。所有能够继承它们父类既有的基因, 且自身具备独立的品牌认知心理的业务, 通通会在实际运行的期间真实地呈现。能够借助对象这种方式, 达成破除诸般兄弟之间所产生的相互作用影响。具有核心控制性的基因是不可以加以改变的, 然而, 新能力的创造就是能够脱离父亲所产生的影响从而实现独立发展, 同样地, 也能够创造出来全新的子业务。
与此同时, 我们需要构建一套业务对象协作机制, 天猫与淘宝彼此相互协同一致, 大麦和飞猪之间是能够协同的, 使得业务与业务之间生成连接, 共同拼合成为一个会动态繁衍的生态体系。倘若我们能够把阿里巴巴整个商业体系以图示形式呈现出来, 买家迈入淘宝天猫就恰似接入了游戏一般, 步入天猫超市就好像真的进入某一家超市, 去做拍卖真的犹如要敲锤一般, 营造出虚拟世界的真实感。
阿里巴巴业务平台经历着这样的演进, 先是以功能作为中心, 随后转变为以商业能力作为中心, 然后又转化成以业务作为中心, 而我们正行进在这条道路上。
你可能还喜欢
点击下方图片即可阅读
关注「阿里技术」
把握前沿技术脉搏
