复杂系统的持续架构

复杂系统的持续架构右军目录我的架构演进观架构范式的三种形态从企业架构到软件架构持续架构演进的6准则持续架构方法解析（案例）技术负债的识别和解决组织架构：康威定律围城中台拆解：没有银弹01

我之架构演进观架构是设计出来的，也是演进出来的软件架构的定义组成派软件系统的架构将系统描述为计算组件及组件之间的交互---Mary

Shaw《软件体系结构：一门初露端倪学科的展望》决策派软件架构包含了关于一下问题的重要决策软件系统的组织选择组成系统的结构元素和他们之间的接口，以及当这些元素相互协作时所体现的行为如何组合这些元素，使他们逐渐合成更大的子系统用户知道这个系统组织的架构风格：这些元素以及他们的接口、协作和组合软件架构并不仅仅注重软件本身的结构和行为，还注重其他特性：使用、功能性、性能、弹性、重用、可理解性、经济和技术的限制和权衡，以及美学---Rational统一过程架构演进的原因满足业务需求研发效率问题业务发展问题质量属性：如可用性监管政策/法规某垂直电商2010-2015年，业务在超高速发展，每年保持

3

倍以上的增长。单体架构系统呈现几个问题：1、业务创新多，代码逻辑穿插复杂，发布跟不上需求2、系统稳定性和容量存在挑战。某电商早期主要采用

.net构建，曾在大促因业务火爆宕机，CEO发微博请信息化部门同事喝茶。后续几年，技术架构进行了代际变化。支付宝交易号早期一天限制一亿美国航空公司Comair在2004年因机组调度系统崩溃，再加上恶劣的天气，导致大量航班取消，迫使机组人员重新安排航班，但航班分配系统有一个限制：每个月3.2万次机组分配、查询某年雅安突发地震，人们涌入捐赠产品热心捐款，捐赠系统性能和容量告急，连夜紧急扩容、查询SQL性能优化个人信息保护法中国人民银行金融消费者权益保护实施办法国家新闻出版署关于防止未成年人沉迷网络游戏工作的通知渐进式架构演进收银台支付决策决策引擎外部依赖（资产、渠道路由、会员…）支付决策决策引擎外部依赖（资产、渠道路由、会员…）流出决策收银台支付决策决策引擎外部依赖（资产、渠道路由、会员…）流出决策机构交换决策收银台 流出产品流出产品机构卡中心代际架构演进淘宝外部B2C航旅账单业务。。。银企直连网银信用卡红包渠道优惠...快捷支付淘宝外部B2C航旅账单业务。。。银企直连网银信用卡红包渠道优惠...快捷支付目标驱动架构：架构演进的三种形态没有一定的目标，智慧就会丧失；哪儿都是目标，哪儿就没有目标。——（法国作家）蒙田02烟囱型架构（1）特点：项目需求驱动优势：短期目标明确，可以集中兵力上线。客观上业务隔离，失败业务关停对其它业务无影响劣势：重复功能建设和维护带来的重复投资打通烟囱型系统间交互的集成和协作成本高昂。不利于业务的沉淀和持续发展技术团队按照业务形态成比例增长，不经济烟囱型架构（2）案例出自《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》（钟华）P242003年成立淘宝事业部2008年成立淘宝商城（天猫）2套独立的体系，2套电商平台都包含了商品、交易、评价、支付、物流等功能2009年，共享业务事业部应运而生，一度被2大需求方资源挤压2010年，聚划算爆款，业务强制通过共享业务事业部接入，平台对淘宝/天猫/1688

对话权拉平。沉淀共同平台。平台型架构（

1

）券平台服务：创建模版、发放/领取券、核销、过期……核心领域：平台化的第二个案例平台化的核心收益其实就是降本增效：抽象共性，

减少重复建设投入的人力和时间成本。快速支撑，

提高需求到研发上线到效果复盘各环节效率。什么是中台来自阿里官方的定义，“企业中台就是，将企业的核心能力随着业务不断发展以数字化形式沉淀到平台，形成以服务为中心，由业务中台和数据中台构建起数据闭环运转的运营体系，供企业更高效的进行业务探索和创新，实现以数字化资产的形态构建企业核心差异化竞争力。”中台型架构案例出自《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》（钟华）解法：XXX的总体架构是：前端和接入层前台业务业务中台和数据中台基础设施企业效能和运维保障体系从企业架构到软件架构当忙于奔跑的时候，不要忘了为什么出发03企业级业务架构设计From：《企业级业务架构设计：方法论与实践》（付晓岩）企业信息架构体系素材来自百度图片搜索基于业务领域和职责做演进：2012年之前的账单业务XXX账单日常生活中经常遇到的定时需要缴纳的单据，如水费、电费、煤气费、有线电视费、信用卡还款等跟生活息息相关的，由各服务事业单位提供的收款单据。出账机构指每月创建帐单的机构，包括电力公司、自来水公司、煤气公司等公共事业单位，也包括电信、移动、联通等运营商，还包括交通管理部门、税务部门等。销账机构具体缴费往往由银行等机构代收。出账机构在销账机构开设账号。用户按照账单支付。用户侧业务活动：1、填写信息：选择缴费单位填写户号2、查询账单3、支付4、查看缴费记录5、设置提醒6、设置代扣平台侧业务挑战：1、公共事业业务的特点以城市为单位，不同城市出账机构不同，需要一家一家接。2、业务推进速度快3、业务种类和形态，不少业务非常个性。种类上往交通罚款、物业等等拓展技术侧挑战：1、重复建设，标准化不够，如不同产品都有对账处理2、700+

行的超级DTO对象，散落的各种逻辑处理3、出帐机构有700多家，非常个性化，系统对特殊的业务做了非常多的个性化处理，给维护和未来的业务发展增加了成本。一度缴费的渲染页面有20多个小页面。4、页面逻辑写死，PC/移动版代码重复基于业务领域的洞察做架构演进（案例）对账中心账单中心账单网关出账/销账机构水电煤缴费产品交罚缴费产品信用卡还款产品X缴费产品出账/销账机构EBPP（电子帐单处理及支付系统）：通过电子方式实现各种帐单的整合、处理、传送与支付。举例来说，一个普通家庭（或个人）加入

EBPP

项目后，即可以通过互联网定时接收到自己的各种公用事业费用账单（水、电、通信费用等）或其它账单（如保险、教育等），然后通过网上支付的方式，即时支付这些账单，并可随时查询详细情况。职责统一，三类对账方式平台型企业关注：PBC涉及模型乘客司机/服务提供方滴滴uber买家卖家用户餐饮店主餐饮平台出行电商餐饮O2O天猫C

端B

端平台端按不同参与者看SLA交易订单支付收费业务记账消费记录收支明细用户商户对账用户SLA支付流畅度签约服务开通及时准确SLA商户SLA开通时效方便准确商户SLA账单（月、结算账务签约会计支付渠道收单新业务接入收费合规安全财务隐私法务风险资金管理以某支付场景业务接入为例架构师的多维视角架构演进的6准则04

与工具准则是做事的指导，是可以调整的指南；原则是做事的底线，更严肃和稳定。机械工业出版社 杨福川持续架构6准则Principle1:Architectproducts;evolvefromprojectsto

products.准则1：产品思维，而非项目思维来设计架构Principle2:Focusonqualityattributes,notonfunctional

requirements.准则2：聚焦质量属性，而不仅是功能性需求Principle3:Delaydesigndecisionsuntiltheyareabsolutely

necessary.准则3：在绝对必要的时候再做设计决策Principle4:Architectforchange—leveragethe“powerof

small.”准则4：利用“微小的力量”，面向变化来设计架构Principle5:Architectforbuild,test,deploy,andoperate.准则5：为构建，测试，部署和运营来设计架构Principle6:Modeltheorganizationofyour

teamsafterthedesignofthesystemyouareworkingon.准则6：在完成系统设计后，为团队做组织建模Neal

Ford《演进式架构》演进式架构支持跨多个维度的引导性增量表更系统绝不是其组织部分的总和，而是各部分相互作用的产品。——RusselAckoff

博士没有指导原则，演进式架构无处谈起。适应度函数为某些架构特征提供了客观的完整性评估所有的业务单据必须明细级核对操作库存事件，全部纳入服务响应小于

100ms：(99%,每5s采集)所有优惠事件，纳入事件稽查安装包大小不增加系统质量分>=45,且不降低架构师确定top级维度静态代码质量性能业务安全性可审计性资金安全……持续集成、持续部署数据客观可量化Neal

Ford《演进式架构》组合不同类型的适应度函数原子适应度函数+触发式适应度函数关注点：循环依赖，圈复杂度…手段：单元测试、功能性自动化测试+持续集成整体适应度函数+触发式适应度函数关注点：性能、可伸缩性…手段：持续集成、持续部署原子适应度函数+持续式适应度函数关注点：一堆接口是否正确返回错误码…手段：

测试代码

+

工具整体适应度函数+持续式适应度函数关注点：资金安全、业务安全、可伸缩性、可用性…手段：Chaos

Monkey、红蓝计划性攻防、突袭演练TheSimianArmyisasuiteoffailure-inducingtoolsdesignedtoaddmorecapabilitiesbeyondChaosMonkey.WhileChaosMonkeysolelyhandlesterminationofrandominstances,Netflixengineersneededadditionaltoolsabletoinduceothertypesoffailure.SomeoftheSimianArmytoolshavefallenoutoffavorinrecentyearsand

aredeprecated,buteachofthemembersservesaspecificpurposeaimedatbolsteringasystem’sfailureresilienceGitHub：Scientist周攻击次数百次，支付宝疯起来连自己都打2014年，专门成立了技术质量部，从全域视角解决技术风险的问题。2016年，技术风险部再次升级为SRE团队故障自动定位、自适应容灾、防抖、精细化高可用2016年，技术蓝军成立红军：核对异常发现能力2017年，智能核对平台蓝军：故障场景挖掘平台2018年，每周数百近千故障场景发掘持续架构演进的维度05不识庐山真面目只缘身在此山中李白a2m.msup.com.cn业务种类、商品种类扩展业务规模发展环境维度组织：团队拆分组织：公司并购监管合规：政策要求服务区域维度互联网架构演进的主维度用户：一百万

到一千万IM交易量：一百万笔

到一亿电商平台个人信息保护法中国人民银行金融消费者权益保护实施办法国家新闻出版署关于防止未成年人沉迷网络游戏工作的通知美团和大众点评合并阿里巴巴收购饿了么业务出海线上到线下外企孵化本地化产品linkedin

赤兔猎豹杀毒和清理产品淘宝

～天猫Uber

：叫车、送花、送蛋糕滴滴

：网约车、专车、顺风车美团外卖： 送外卖、送花、送货a2m.msup.com.cn业务拓展+业务规模Uber：网约车 拼车UberMoversUberCHOPPER旧系统是为专用客车运输所设计的，做了很多假设：1、每个车辆一个乘客，不适用

UberPool（拼车服务）。运送人的想法深深嵌入到数据模型和接口里。2、这样限制了扩展到新的市场和产品上，比如运送食物和箱子。3、最初的版本是按城市划分的。对于可扩展性而言是好的，因为每个城市可以独自运营。但当越来越多的城市加入，这变得越来越难以管理。城市有大有小，负载也不一样。业务规模发展（1）案例：跨越篱笆——蘑菇街每秒最⼤大订单数25倍提升历程（白辉）业务规模发展（2）案例：跨越篱笆——蘑菇街每秒最⼤大订单数25倍提升历程（白辉）滴滴案例（1）：2017年底业务的复杂性实时性O2O业务的场景差异不明确且持续变化的需求组织的复杂性7+个事业部

400+个城市更快变化的组织和个人from：如何构建出行中台

（赖春波

）from：滴滴业务中台构建实践

（何修峰

）from：如何构建出行中台

（赖春波

）滴滴案例（2）：2017年底技术负债的识别和解决06随着一个不断发展的项目不断变化，它的复杂性（反映了结构的恶化）会增加，除非采取措施来维护或减少它。— Meir

Manny

Lehman（梅厄·曼尼·雷曼）,

1980随着一个不断发展的项目不断变化，它的复杂性（反映了结构的恶化）会增加，除非采取措施来维护或减少它。— 梅厄·曼尼·雷曼,

1980“交付第一次代码就像欠债一样。只要通过重写及时偿还，一点点债务就会加速开发......当债务没有偿还时，危险就会发生。花在不完全正确的代码上的每一分钟算作该债务的利息。整个工程组织可能会因为未合并的实施（无论是面向对象的实施还是其他实施）的债务负担而陷入停滞状态。”— WardCunningham

1992Muchlikefinancialdebt,technicaldebtcanbeutilizedinbothgoodandbad

ways.永远不偿还技术债务的代价是显而易见的；最终，提供功能的成本将变得如此缓慢，以至于设计良好的竞争性软件产品很容易在功能方面超越设计糟糕的软件。根据我的经验，设计糟糕的软件还会导致工程人员压力更大，进而导致更高的员工流失率（这反过来会影响交付功能时的成本和生产力）。此外，由于给定代码库的复杂性，准确估计工作量的能力也将消失。如果开发机构按功能收费，那么交付代码的利润率最终会下降。—

JunadeAli

《掌握

PHP设计模式》技术债务四象限故意的无意的谨慎的鲁莽的当产品的风险相对较低且快速交付的好处大于风险时，最常使用这种类型的债务。知道如何编写最好的代码，但优先考虑快速交付技能和知识不足，产生的技术债务在实现后发现更好的解决方案增强技能加强培训代码规范行业领域借鉴迭代债务列表管理债务列表管理债务列表管理债务度量（适应度函数）偿还计划处理/

应对技术债务在实现后发现更好的解决方案1、跟踪系统中维护债务列表：每次您产生债务时，请将偿还债务所需的任务以及估计的工作量和时间表输入到您的跟踪系统中。任何超过

90

天未解决的债务都应被视为关键债务。2、内建质量与度量魏文王问扁鹊曰:「子昆弟三人其孰最善为

医?」扁鹊曰:「长兄最善，中兄次之，扁

鹊最为下。」魏文侯曰:「可得闻邪?」扁

鹊曰:「长兄於病视神，未有形而除之，故

名不出於家。中兄治病，其在毫毛，故名不

出於闾。若扁鹊者，鑱血脉，投毒药，副肌

肤，闲而名出闻於诸侯。」内建质量3、ROI

评估：3-6个月提前量、在晴天修屋顶4、放弃技术洁癖（Everything

皆成本）组织架构：康威定律围城07你让3个团队去做一个产品，他们第一件事就是做3个系统。lzhuacuo组织沟通方式会通过系统设计表达出来时间再多一件事情也不可能做的完美，但总有时间做完一件事情线型系统和线型组织架构间有潜在的异质同态特性大的系统组织总是比小系统更倾向于分解康威定律案例1关于中台的去魅和真实08回顾：

平台化平台化的核心收益其实就是降本增效：抽象共性，

减少重复建设投入的人力和时间成本。快速支撑，

提高需求到研发上线到效果复盘各环节效率。平台化之后，已经足够内聚和抽象但是站在业务视角，整体效能仍然堪忧解法：中台化其实是平台化之后的自然阶段，它主要是带来了：提供完整解决方案而不是暴露

API，给业务带来的快速创新和试错能力的提