软件平台架构设计与技术管理之道笔记

认知

领导软件平台各方面的工作，对技术底蕴、思维模式、决策能力、工作风格、文化铸造等方面都有极高的要求，可以称之为“领域智慧”。认知盲区的代价是巨大的，“不知”比“不会”的后果更严重，可能导致方向性的错误。

庞大的科技队伍，可谓千人千面，管理工作中出现举棋不定、迷茫不清时，唯有以扎实的认知作为心理的定海神针，切不可做无根之水。

在繁冗、枯燥的IT技术工作中，埋头干活不能忘记抬头看路，主动发现更多的“艺术”细胞，增加更多的抽象领悟，终会拨云见日。

在工作陷入僵局时，回到认知上去审视自我，助力破茧而出。

一般而言，技术总监职责重在团队建设与管理，并对任务完成情况负责，架构师则主要在工程和技能领域发挥作用，CTO更具统领价值，除了更多的管理层事务和外联类工作外，还应建立行业影响力、取胜于格局。

硬实力是必需的基础，而软技能则决定着技术负责人的最终画像，驾驭平台更需要“软实力”加持。

如果能成为开源社区或论坛的活跃者，或者是行业规范制定的参与者，以此来提升自己在相关领域的影响力，则更是加分项。

平台的市场竞争力，很大程度上取决于前端的能力，用户体验和外部评测，直接反映了平台大前端中异步通信、懒加载、压缩、渲染等能力的强弱；产品迭代发布的速度，直接取决于前端组件化、模块封装复用的架构力和打包部署能力；对行业新技术、新生态的跟进，则依靠前端团队技术栈和语言的学习与运用能力。

前端领域还是安全问题、兼容性问题的重灾区。

分布式开发框架解决了单体应用的扩展和演进问题，带来的弊端是逻辑角度的系统越来越多，跨进程系统服务之间的交互越来越多。

云技术的广泛应用，服务网格化、开发运维一体化需要掌握和使用云原生能力。

行业技术发展加速了分工细化，后者反过来进一步催生技术再发展，如此循环上升，技术人员必须克服“被其绑架”的困境。

平台技术负责人已经不可能在各个细分技术领域都是专业上的通才，无法将主要精力放在技术深度方面。面临着技术团队庞大化、技能差异化，技术负责人工作价值和竞争力的体现，必须聚焦于“平台技术能力视角”的整体蓝图，作为各条产品线开发团队的总架构师、布道师，进行全局分域规划、应用系统及服务的颗粒度设计、能力支撑和公共抽象、平台级的组件建设，并编排各条产品线间的服务治理、系统间关系、技术复用，清晰知道目前进行到哪个阶段，筹划要具备什么能力，价值是什么，以及对问题的合理性技术决策。

鱼与熊掌不可兼得，技术部门内部的工作决策，尤其是技术主张、架构设计类，经常出现没有正确答案、各个团队各执一词的场面，就其本身而言确实是客观的，例如，引用新技术的风险与机遇、微服务拆分的颗粒度、几种开发框架的选择、系统间关系设计及通信协议的选择、对业务数据迁移的风险估计等，或者是开发周期短与测试把关要求严之间、质量与交付速度之间、快速解析数据与使用高强度加密算法确保安全之间……无处不在的矛盾体。技术决策的选择，不会出现简单的答案，各类设计、各种主张都有各自的道理，需要技术负责人承担决策责任。

没有完美答案

决策并不是给出完美的答案，决策的核心，是在有限的时间内尽量充分地沟通，合理进行“取舍”，其根本是门“折中”的艺术，以达到一个平衡的目标，多数情况下你并非是以某一个选择作为结果，而是多个观点之间的平衡点。

独断专行的决策方式是极左，过于民主协商的决策方式为极右，两者都有缺陷。

最佳决策应该是在创意择优中，按照观点的可信度高低来得出，圈定参与决策的人员，每人提出自己的观点，对于能力强、责任大的人员，还应该在过程中努力解决彼此分歧，不同能力者观点的权重不同，进行可信度加权产生决策参考结果。

决策者没有必要凡事都做出判断，但是必须能够适时终止辩论，知道如何超越分歧，推动就下一步措施形成共识。有时延时决策（如放到下次会议上决定）是很好的缓释方式。

用心记录决策理由

对于架构设计工作，用心记录的决策理由，其本身就是一套架构演变文档，无论如何这类材料都物超所值。

掌握和使用行业的成例方式作为参考，在很大程度上，可以帮助我们尽快选定合适的“方法论、表达模式和工具支持”。

“架构视图”一词，确系经典，但更给人以“从剖面、窗口看到的内容”之感，侧重结果的表达，含义略显匮乏。（如典型的4+1架构视图：逻辑视图、过程视图、物理视图、开发视图、场景视图）

“架构主题”，更具有对特征的识别、分析，以及主旨探索之意。形象化看，一个视图是整个平台的横切面。而前端技术架构、大数据架构、统一身份认证架构等是平台纵向的组成部分，是一个个领域，并非某个视角的全平台横切面。严格说，架构设计的对象，并非几个经典视图，而是包含了一系列的领域对象。既有横切视图，也有纵分领域的情况下。

可以借助一些有助于架构决策的方法论工具，如架构权衡分析法、成本收益分析法、ADMEMS方法等。

架构的发展历程

第一代是单体(Monoliths)架构：

• 特点：水平分层

• 优点：容易上手、部署和测试

• 缺点：耦合性高、技术选型单一、开发效率低下

第二代是面向服务架构(SOA)：

• 特点：垂直分层，系统之间通过Service API和中心化管理的企业服务总线(ESB)进行交互
• 优点：服务化整合和治理
• 缺点：每个服务从本质上还是单体服务，对ESB严重依赖

第三代是微服务(MicroService)架构：

• 特点：水平分层与垂直分层结合，将单应用程序作为一套小型服务，分布式技术

• 优点：

  有服务注册、熔断、容错、自检测、自动发布等能力；可快速迭代及持续交付。微服务架构与分布式开发框架相辅相成，体现了小团队自治和快速迭代产品发展。

  微服务实际上是面向服务架构的一个更好的替代，即去中心化的分布式服务架构(DSA)，将服务寻址和服务调用完全分开，不再依赖于ESB。

第四代是云原生(Cloud Native)架构：

• 特点：基于微服务思想，以容器为载体，提供一种产品研发运营的全新模式。

• 优点：

  在开发和运维方面包括：基于云的能力，资源动态管理；Docker容器技术；Service Mesh服务网格；Serverless无服务器架构；API服务化；轻量服务无状态化；Restful风格化；自助管理资源；持续集成(CI)持续交付(CD)；DevOps开发运维一体化、自动化。

欲言架构，必言模式

在内容表述上不论是偏技术形态，还是偏思维理念，本质是能够用于特定问题的可复用解决方案，这就是模式。模式无处不在，好的设计方法实际就是模式，没有实际边界。

软件架构的基因，具有天生的“模糊性”：

到底什么是软件架构，核心是模式与工具，还是理念和思想？模式是风格吗？微服务到底是架构模式，还是架构风格？架构模式与设计模式，在实际工作任务中，它们真地有界限吗？

上面这些问题，不同专家会有不同的答案。

四代架构的发展历程，体现的是核心理念、风格和模式在几十年间的实践，并非是银弹技术。和前三代具象的描述方式不同，第四代架构的定义已经模糊化，是广义的能力包，更多的是对应云技术的广泛应用。

但是当前四代架构代次的定义方式，未来无法覆盖全部主流。算法开发人员的职业规划，估计没能从云原生架构中获益，Hadoop大数据开发者，对微服务架构也不甚关心。

未来可能没有任何一个词能独自站出来，承担起对第五代架构的缩写定义，取而代之的是各个领域的分支发展。

不论有无第五代架构，其实际意义已然消散。而且，不应认为后代比前代好，好坏之说过于绝对，只能说后代是面向行业发展的新产物，软件本身不是目的，只有是否适合目标之分，如果要做一个很简单的小Demo，仍然可以用单体理念，找一个最原始的技术栈来实现。

不断涌现的架构代次之说，是为表达发展趋势下的主流潮流，以及新理念、新技术落地的模式方法。

不应认为架构是“银弹”，不应该将过多精力置于考量架构模式的话题上。要明白的是，大量的设计方法更广泛存在于程序语言中，编写整洁的代码和使用自动化测试，对于系统的成败更为重要，这仍是现代化软件研发工作的核心。

无为而治

老子《道德经》中所讲治国水平的四个层次：

最低层次凭“管理者智力、智谋”，

其次是使用“规章制度、条文规范”进行正规化的管理与约束，

再高的档次是“包容、仁爱”的美德级别，

而四层级的最高档次是“无为而治”。

无为而治需要更多地站在一边观察，不要急于发挥自己的权威，也不需无处不在的“积极努力”，技术负责人缺少的可能是倾听。

学会放手是管理精髓的真正领悟，技术负责人应该注意团队是否按照设计和工作计划实现系统，但是没有必要站在背后监视大家。

下放工作权限，给予团队成员足够的自主和自治，让他们发挥自己的创意和能力，或许才是技术负责人的最大价值。

架构设计思维原则与模式

架构设计思维原则与模式

• 以人为本：

  设计工作的本质是人与人的交往。理解相关方要求，驱动下属团队认知。尊重所有干系人，换位思考。

• 延时决策

  模棱两可的工程是危险的，不到条件成熟的那一刻，不要着急做出最终的设计决策。

  有些甚至可以放到工作范畴之外，留给后来的设计人员去决定。记住，这绝不是逃避责任。

• 借鉴复用

  完全可以在别人的基础上开始自己的设计，或者使用别人已经搭建好的框架来解决问题。设计架构时，必须花更多的时间研究已有的设计，减少自己创造，避免低效的产出方式。因此，广泛阅读、认真学习过大量设计模式的人，只要没有模式病，就会显得能力更强。

• 化虚为实

  让受众通过感性的认识可以理解和消化，如果无法让他人接受想法，再好的设计理念和创意也无法产生价值。

• 理解

  研究利益相关方关心的业务目标，理解重要的业务需求内容，更要了解非功能需求，包括开发团队的资源、风格，甚至是办公室政治，均要做到悉数掌握。

• 探索

  对概念进行定义时的科学性和严谨性，架构设计探索，是指形成一系列设计概念，确定解决问题的工程方法，包括研究大量的模式、技术和开发方法。

• 展示

  展示，不仅体现四原则中化虚为实所强调的让他人理解和接受你的设计想法，并且供架构评估和校验所用。展示想法实际就是架构工作的输出，推进协商、制订计划。因此，需要注重如何提升架构成果的表现力、表达力。

• 评估

  分享架构的唯一方式就是把它具体呈现出来。很容易理解评估对验证架构设计适用性的作用，用于判断是否满足各个干系方的需求。

擅长技术和善于向上管理是两种不同的能力类型，技术负责人需要两者兼顾，就价值和资源来讲，一万行代码也比不上一次领导认可

架构

分界思维

针对大型软件平台的业务需求进行技术功能设计，应该参考或者遵循DDD方法，作为最佳实践指导。运用限界上下文设计模式，识别出所有的上下文（即基于业务的问题空间），根据核心域、支撑域、通用域几种类型对上下文归类，对应形成各个分类的领域模型，通过上下文映射(Context Mapping)技术来设计各域之间的关系。

限界上下文的精妙之处在于，微服务本质上基本等同于DDD中的限界上下文，可以以此来设定微服务颗粒度。分界思维不仅适合新平台、新系统的建设，尤其适用于对“大泥鳅”遗留系统的整体重构类任务。

架构模式和设计模式

模式为软件架构师提供了最具价值的工具，可以理解为：模式按照级别分层，可分为架构模式和设计模式，前者相对高阶，旨在提供系统架构的整体骨架，后者颗粒度更细，用于解决常见问题，如某一系统的组件（或者某业务中关键技术）级别的组织、通信等。

模式是技术前辈们将设计方法进行抽象提炼，总结而成的模板和工具，便于后人复用，从而帮助我们简洁有效地进行技术设计工作，这才是正确的用法，必须保持对一切技术任务的洞察力，以提供切实有效的、服务于业务的方案，进行适度设计，获取平衡之道。

在平台建设中首先进行最小化实现，即早进行部署，确立架构。实现“立起架构”：第一时间打通开发、测试、部署、维护的路径；第一时间打通从前端工程脚手架，到前后端通信，到后端访问缓存、数据库和使用管道……第一时间验证各服务节点的服务注册与发现、通信机制有效性，甚至是负载均衡的可用性。

保持架构一直处于可用状态中，进行递增部署，利于建立整体朝着正确方向前进的信心，一系列串行工作因此变得更具弹性。并非所有产品都要等到十全十美才能发布，递增式部署，意味着在可以运行的架构基础上，增量式、有选择地进行培育，迭代式验证。

打通数据模型

数据模型是什么？本质上，包括对实体、关系和属性的定义，以及所使用的范式。不同的范式，在数据冗余与数据完整性上，给出不同的原则和约束。

目前数据库的发展历程可以分为三个阶段：

• 第一阶段：2000年后的10余年，大型商业数据库的天下

  如 Oracle、IBM DB2、Teradata

• 第二阶段：约2006年之后，MySQL 等开源数据库

  开源属性催生了集群化部署，以及分库分表、读写分离技术的广泛应用，实现了投入成本与性能之间的真正平衡

• 第三阶段：从2012年至今，以大数据产业驱动和分布式计算发展带来的Hadoop生态圈

  包括NoSQL、HDFS存储、非结构化数据库（如HBase列式数据库）以及数据仓库(Hive)等

前两个阶段，最核心的进步在于互联网思维和开源技术带来的数据库软件技术的飞跃，但是“数据存在的形态和主要的应用模式”这些最核心的要素并没有变，主流都是SQL标准和范式下二维表的结构化存储和输出形态。

数据库领域的技术一直在变革，但“内容为王”的属性和理念一直没变，打造坚实的数据库堡垒的系统建设思想，20年来从未发生变化。

用户界面和应用逻辑会变化，业务会发展，人员会变动，但是数据会永远保留下来，不论二维结构化、还是列式非结构化数据，都改变不了数据的不可变特性。鉴于数据的这些特点，创建牢固的数据模型，要从第一天开始。

内容为王的另一层含义是，数据库在企业安全角度被赋予最高使命，数据是系统中最高安全级别的，是企业中最值钱的资产。

应用可以再造，没有数据则一无所有，平台运维工作应在数据库和核心数据上多下功夫。加密和脱敏、冷／热备份是平台的基础必备能力，同时，定期攻防和切换演练、灾备中心建设、各类资质和评级，此类重要的运维工作，都应该以数据为首选主题。

掌握运行水位线及定期演练

进行平台水位线管理，主动掌握系统的运行压力线，知己知彼则百战不殆。一般有三类方法进行运行水位线评估：

一是TPS的估算法，

二是操作系统资源使用率估算法，

三是历史值估算法。

定期演练的工作机制可以用于揭露“水面下的冰山”。主备中心级别的切换演练、物理机的宕机演练、核心数据库的停服演练、网络DNS解析服务商更换等，都是良好的演练主题，切记，“实际演练发现问题”比“一万次会议强调自查”更管用，这种良性的、自揭伤疤的方式，是应对技术人员“自查自提升”惰性的最佳手段。

运维手册与技术白皮书

运维手册要定位在熟知所有要素，需要时立刻能找到。

故障排查可能更适合放入运维知识库中，以问题及处理方式列表体现更佳，运维手册是故障排查工作依赖的关联材料，无法在运维手册中预见出所有的故障场景。

对于技术白皮书的理解，行业技术工作者认为更适用于底层技术应用，例如，针对一种通信协议、一种存储技术的白皮书，更看重于技术原理和规范，内容深入且翔实，是完完全全的专业技术文件。而对于区块链这种大咖级别主题的技术白皮书，则更体现为一种行标，甚至是国际标准形式。

应用类系统平台的白皮书，更通俗的理解是平台对外发布的标准服务、接入和集成方式，供任意开发者在授权方式下，以边界严格但实现形式开放的方式，进行二次开发或者客户端接入，这类白皮书其实就是面向开发者的、高规格的技术手册。

建议技术负责人能够组织、联合各个技术团队，每年定义一个年度级别的大版本，编制发布一次面向公司的技术白皮书。主要内容可以包括：

• 各类内部标准规范文件：接口规范、开发规范、操作规范、数据库规范等等
• 对平台级能力进行高度抽象表达
• 技术白皮书最重要的部分，郑重表述平台的容量、TPS/QPS（并发性能）、SLA（平台可用率）指标、RT（服务响应时间）指标等
• 交付及质量方面的统计数据，年度发布版本数（及对应的需求数量）、平均交付周期等

模型与代码的融合

领域模型是DDD的核心，架构师在设计模型中包含的想法如果无法在代码中体现，模型与代码相脱钩，那么如性能、可用、扩展等各类非功能性设计的思考与推演，也将无用武之地。因此，务必要关注将领域模型融入代码，减小代码与模型之间的偏差。

代码包的组织方式，不论是分层组织还是分功能模块组织，与设计的模块结构相匹配，能够突显架构，应该将此作为标准的开发规范。

落实架构元素间使用关系的清晰和准确，需要关注代码模块结构中的访问限制，或者是将模块作为库分发，如果这些都无法做到，那么可以考虑使用工具来监控这些使用关系的问题。

做好契约式设计，在代码中设置使用条件，并在运行中进行检查，如果违反契约，应该抛出错误并终止运行，包括对象、服务、线程、进程，各种颗粒度都可以采用。

将代码模块升级为组件，通过微服务架构进行组件级的调用管理，通过容器进行组件级的进程封装和轻量级分发，是对模型落地进行管控的良好方式。

除此之外，还可以依靠传统的代码评审会，来进行模型与代码融合的检查。

顶层设计

在对业务需求的分析基础上，必须立体展开，为平台尽量多地打标签，对这些标签的定义和对问题的解答，正是平台架构设计的驱动力。技术架构工作的输出物，通俗的理解是：“从多个切面、视角、维度，对软件平台及所实施系统的丰富表达”。各个切面能表达出来，整个平台的架构设计也就出来了。

分层总体架构

分层架构是一种最通用的、在行业使用最为广泛的架构模式，尽管微服务思想和分布式架构已经普及，相比于国外使用较多的六边形架构范式，国内还是最热衷于使用分层架构，其特点是：简单易懂，容易绘制，能最大限度地同时表达出用户层、业务功能、技术组件、底层数据、操作系统及基础平台环境等多项内容。

面向领导、商业方、合作伙伴等各类不同沟通对象，考虑立项、汇报、基本陈述、培训等各类工作场景，唯有此架构表达范式最具通识性。

所有架构主题中，分层架构是颗粒度最大的，也是应该最先做的。主体内容使用水平分层（每层都是水平长方形），上层依赖于下层对其提供支撑，从上至下，形成典型的划分方式。

可以分为：

• 用户层：

涵盖所有客户端类型：C端移动App、小程序、PC端浏览器等

• 网关层（也可定义为接入层）：

主要表达产品输出的形态，描述网关系统、API、文件传递等各种接入方式；描述用户层接入的网络链路，包括互联网、专线等；描述网关层的定位和功能职责，如服务发布、接入者身份认证、密钥分发、协议转换、请求路由分发、流量控制等

• 应用层：

即为应用系统层，也称之为业务逻辑层。

描述平台要实现的若干个系统（或模块），可以按照DDD分类方式，分为核心域、支撑域、通用域三类。

应用层是总体框架中最重要的一层，是其下面各层的产物，对其上的用户层提供业务服务，在此表达整个平台最终做出什么产品和业务服务。

• 技术能力层

技术能力层又称为共享的（或公共的）技术组件层。这是逻辑角度的技术架构核心，在这一层需要体现平台的技术组件，可以包括消息通道、日志服务、搜索服务、脱敏加密、规则引擎、BI报表、指标计算等通用基础技术的封装和输出，以及如文本解析、图像识别、语音处理、实时视频等平台业务所需的特定组件服务。

如果说应用层是分层架构中的最重要的角色，那么组件能力层则是架构师工作的最重要的领域，作为全平台的技术共享中心，是所有技术组件、业务组件的制造车间。

• 外联服务层

包括技术类和业务类两类外联服务。

一是描述平台访问的技术类三方服务，包括邮箱、短信类服务等

二是描述平台对外访问的业务合作伙伴端提供的服务，例如支付服务等。

例如平台支付服务连接到银联、网联或者××银行，这样平台的全部业务合作伙伴会一览无余。

• 中间件层

描述平台运行所依赖的各类技术中间件，包括使用的应用容器及环境，主要的通信协议、缓存、负载均衡、应用配置和服务注册、大数据处理软件等。

因为数据的核心地位，很多分层框架会为数据库划分出单独的一层，即数据持久化层，来重点表达数据和文件存储。

• 平台能力层

如果使用××技术的云平台，应该在这里表述，并在这里提供原生能力，例如内部网络划分、资源管理及容器、服务编排、灰度发布、服务降级能力。

• 其他板块

在左右尽量增加几个竖直长方形，将运维、测试和管理板块的信息一并装入，使得总体架构更加全面。包括使用的代码仓库、构建和发布工具、代码检查工具、文档知识库、项目管理工具、测试工具。

交互关系设计

交互关系设计，按照颗粒度和目的不同，可以分为“交互流程设计”和“系统逻辑关系设计”两类。交互关系设计侧重于反映相干系的各个角色、各端之间的业务功能联系，技术关系并非其要点。

交互流程图设计

交互流程图，本质设计的是业务处理流程，包括各个环节点（流程处理点），以及处理点之间的时序交互关系。

交互流程的最佳实践，一定是以用户访问开始，以服务完成终止。

一个交互流程图所包括的交互环节的数量，应该适中，20～30个是个讨人喜欢的数量。

除了使用泳道图外，还可以使用称之为立体图方式的表达交互流程。

泳道图示例

立体图

立体图细节

系统逻辑关系设计

系统逻辑关系作为另外一种交互关系表达方式，描述平台内各个应用系统之间的（业务接口）服务调用关系，对技术类（例如加密机）系统和共享技术能力（如短信通道）的调用，不必纳入其中。

系统间服务接口众多，没有制式可参考，一般为自由发挥的立体图，绘制门槛比较高，建议在能力、资源允许的情况下设计和维护一份。还有一种办法是将颗粒度由应用系统提高到板块，维护板块间存在的接口调用关系，板块的划分，基本可以与业务（产品）条线相对应，即将同一个业务条线下的应用系统归为一个板块。

数据架构设计

平台顶层的数据架构首先关注划分区域，以数据区域勾画出整体结构性，划分区域所体现的分而治之的思想，是多数架构主题设计的第一原则。数据架构是一个庞大的设计体系，包括业务面、技术面和管理面，每个方面都是高度立体化的，具体分为逻辑视角和物理视角，不难理解，逻辑视角面向业务主题，物理视角面向技术和实现，物理视角是对逻辑设计的技术实现。

业务视角设计

1、划分各个数据大区

完整平台的数据区域可以包括：联机业务处理和交易类数据区（如客户、商户、订单、支付）、业务支撑与管理类数据区（如计费、风控、客服）、数据服务类数据区（如数据推荐）、数据管理类数据区（如数据治理），以及涉及的其他资源数据区（如某行业数据，某公开的服务数据）等等。

2、描述数据主题间的逻辑关系

基于业务视角，描述各个数据主题在平台各个系统区域之间的逻辑关系，以及流转处理方式。

3、进行 ETL 功能设计

对交易类的数据和用于分析、统计类的数据，进行分区治理规划，使用不同类型的数据库，两区间设计详细有效的数据抽取、传输、转换过程。

4、分层规划数据仓库

分层规划数据仓库主要指数据仓库分层设计，一般包括操作数据存储(Operational Data Store,ODS)层、数据仓库(Data Warehouse,DW)层、数据集市(Data Mart,DM)层。数据仓库和ETL(Extract Transform Load)两者之间需要做衔接与融合

5、体现数据管理

数据管理包括数据可视化运营、数据共享、数据权限管理，体现数据分级分类管理内容。

6、体现数据治理

低阶的数据治理包括元数据管理、数据标准、数据质量、数据资产管理，高阶的数据治理应该包括数据标签、数据图谱、血缘关系，甚至是数据沙箱等内容。

工程技术架构

工程技术架构的核心在于设定各大领域所使用的开发框架和各类技术栈，以及所用技术与工程（或者应用系统）的结合。

流量分布设计

流量分布是最能体现美学的平台架构主题，在双中心（一般指主备机房）甚至多中心平台上更为重要，流量之于平台，等同于脉络之于人体，清晰掌握平台的流量分布，等同于医生听心号脉，是各类平台运维工作的重要基础。

此流量是业务请求所产生的“技术流量”，即各系统节点间的调用量。可以叫作链路流量。

链路量的计算方式如下：

• 水平方向

  来看可以分成两段，第一段是平台入口到应用网关之间，第二段是从应用网关进入应用系统区内。

• 垂直方向

  选择合适的颗粒度，将全平台业务板块、功能纵向拆开，单位时间内，某个（或某些）页面、某个（或某些）API的访问量多大。对于每个纵向单位，以业务访问量开始，对完成这个业务请求所访问到的所有应用节点逐级展开，计算其向下过程中的每一次跨节点调用。

链路轨迹上的流量单位不是带宽，而是调用次数。

应用部署设计

部署架构侧重于从逻辑角度描述各级系统的落地模式，即应用系统与平台运行环境的结合，用于应用运维人员和运维相关工作场景使用。应用部署架构不是真正的物理架构，服务器与虚拟机、网络设备等详细的物理信息，不需要直接体现到应用部署设计输出物中。

系统通信设计

通信设计，具体指平台各个应用系统进程之间使用的通信网络、通信方式及所用协议。

这里所谓的“网络”，定位于应用系统通信所使用的网络信道、地址和网络服务，并不包括网络工程（如物理网络、交换机路由器网络设备配置、防火墙策略等）方面的内容。

应用安全架构

安全治理

安全治理主要指安全组织和考核评价体系，以及安全培训、安全保险、合规安全管理。

安全管理

安全管理主要指安全制度体系、员工安全意识和能力建设、系统全周期（从需求分析到上线、运维的全部流程）安全管理、数据使用（申请、存储、传输介质、销毁等）安全管理，以及安全事件管理。

安全技术

安全技术主要包括应用安全、网络安全、主机安全、数据安全，以及办公安全和运营安全等内容

安全审计

安全审计主要包括安全监管、合规审计、风险评估、运维审计等内容。

各种应用安全保障技术措施的运作机制和工作开展策略，可以归为以下三种类型：

实时防护，规则相对固化

如程序加固、接入身份认证，数据传输与存储加密

监测识别，重于模型与策略能力

一是态势感知，做一份流量镜像，监测其安全性；二是风控预警，将业务请求输入风控模型进行分析处理，达到安全阈值设置时进行预警，触发处置策略。

主动攻击，检测技术与评估

即安排漏洞扫描、定期检查、攻防演练等工作，并建立相应的（如黑客攻击）安全技术专业能力和工具。

日志体系设计

日志是系统运行过程中变化的一种抽象，其内容为指定对象的操作结果按时间的有序结合。日志之于系统，可比喻为地下管道之于城市，地下管道表面上看来并不代表城市的建设水平，但是暴雨会说明一切。

日志承载着所有文本类数据，具有极高的可靠性，写日志失败的风险，几乎低于所有其他类型的系统操作。作为平台运转的基石，从全局视角建立日志中心，是中大型分布式应用平台的必然趋势。

日志分层分类：

1、业务日志

2、监控日志

3、系统日志

4、控制台日志

还要考虑日志的聚合与使用：

建立日志中心的最大目的就是将日志聚合后，集中在一个窗口进行查看，可解决频繁登录各个系统节点控制台窗口的安全风险和操作复杂问题。

运行保障

高可用体系设计

(1)全链条冗余机制。

有多路可选，一路有故障时，进行及时自动切换或者故障隔离，不影响整体服务。

(2)防御和降级能力。

对平台进行适当保护，能够将很多场景问题控制在有限的范围内，不至于成为故障。

(3)应用发布保障。

通过灰度发布机制避免应用自身问题造成的平台故障。

(4)应用高性能设计。

指能够应对大的压力，在高压下仍能保持正常的响应时间。

冗余机制的设计

冗余是有A和B两个选择，A不好用了就切换到B，反之亦然，（在不考虑A、B切换中间的那段时间的情况下）平台承载的业务及客户侧体验并没有受任何影响，或者说影响可以忽略不计；

而防御是只有一个A,A不好用了就让它变成A-，以A-的形态来支撑业务，使用A-的这段时间，部分流量无法得到处理或被拒绝，平台提供的服务是打了折扣的。

冗余机制设计的几个方面：

多节点负载探活

最为熟知的高可用技术部署方案是“负载均衡＋应用系统的多节点水平部署”，负载均衡具备节点探活能力，将接收的业务请求按照负载规则（一般包括三种规则，分别为依次轮询方式的平均分配、随机分配或者按固定比例分配）发送到“活的”应用系统节点。

故障隔离机制

故障隔离机制是对简单的、水平冗余的多节点探活机制的封装、升级模式，将有前后调用关系的一组应用节点组成一个单元格，对一个应用的探活变为对以单元格为单位的探活，对不可用单元格进行封闭，不再派发流量。例如，A、B、C三个应用系统级联调用，A部署6个节点，B部署12个节点，C部署6个节点，可以以2个A+4个B+2个C为一个单位，定义3个单元格，负载高可用，由节点升级为单元格。

主备节点实时切换

没有条件做多节点负载探活的情况下，可以利用由Keepalived实现的Web服务高可用方案来避免单点故障。一个Web服务至少会有两台服务器运行Keepalived，一台为主服务器(Master)，一台为备份服务器(Backup)，但是对外表现为一个虚拟IP。这是更为古老的冗余部署机制，但仍然有效。Keepalived所使用的VRRP协议，其目的就是为了解决静态路由的单点故障问题。

应用服务双路

应用服务视角的冗余需要通过自行开发来实现，核心思想很简单，以短信通道为例，选择两家服务商，应用系统实现双接入，不能只选择一个通道，吊在一棵树上。

应用双路是广泛使用的设计方式，更为常见的是资源连接，例如在双活中心下，应用系统连接Redis的配置串、连接MySQL的JDBC配置串，配置的是主地址和备用(StandBy)地址，由应用系统负责探活，实现对资源访问的高可用。

微服务的注册、发现机制

使用微服务分布式开发框架（或者使用如ZooKeeper等框架）提供的服务注册、服务发现机制，实现多节点之间的微服务调用治理，将不可用节点踢出列表，确保服务间调用时选择可用节点。

微服务的注册、发现机制提供的对多个节点服务的可用性管理，不仅是冗余，同样是一种支持高性能的机制，与多节点负载探活的不同在于，微服务侧重于开发框架自身提供的负载和调度能力。

建设容灾中心

容灾中心是最大颗粒度的冗余方案，也可以称其为最极端情况下的运行保障兜底机制，用于应对地震、城市电力故障等其他方案无法覆盖的灾难级情况，容灾可以分为双活、主备等多种模式。

防御降级设计

防御体系用于平台性能或者某链路出现卡点，无法满足全部的外部流量请求时进行的自我保护方式，手段包括限流、熔断、挂维护、超时关闭等策略。防御可以让平台能够避免雪崩，即时自愈，损失最小化。

限速机制

在流量入口处控制客户端请求接入的速度，对超出速度的拒绝服务。

熔断机制

在各服务流量入口处，抽取一定比例的请求作为样本，计算开始接受到返回结果为止的时间，如果其中有一定百分比（如50%）的响应时间大于设定的平台服务响应时限（互联网平台一般为8～10s），则说明该服务不可用，立即拒绝服务（一般持续周期为30s），周期结束后自动打开，如此反复按照周期为单位不断进行。

服务维护

平台高压力下，关闭低优先级（非核心、可被降级）的服务，实现机制一般为挂维护方式，被挂维护的入口链接等于临时被屏蔽下线，或者客户单击时通过弹窗提示系统繁忙或维护中（应该有维护时间说明）。这种方式是一种垂直的服务维护机制。

还可以提供水平的服务维护机制，一个服务的后台应用有10个水平部署的节点，平台高压力下，可以设置让两个节点不响应业务，向前端页面或者API网关返回系统繁忙或维护中的响应码。

简单总结下，垂直维护是关掉所选的服务，水平维护是关掉所选比例的流量。当然可以有最佳的服务方案，那就是垂直＋水平的服务维护模式，以便可以实现关闭哪些服务的多少流量这样精细化的维护能力。

超时关闭

一个请求的完整处理，一般包括多个系统之间的级联调用，也即日志体系设计中所讲的链路概念，链路中包括内部各个系统之间、系统对数据库或外部第三方系统的调用，每个系统均应设置调用的超时时间（一般为3s），超时则断掉连接，从而尽量保护系统端口不被大量的TCP/IP死链接压死，让系统能自愈。

功能降级

低级别功能和辅助类功能，很多由独立部署的系统或者调用第三方系统接口实现，故障率不比核心功能低，对此可以考虑使用预设的“挡板”来进行降级，用于临时救急，不可因此类功能不可用将整体功能阻塞，引起客户投诉。例如，广告服务加载失败，可以用一个固定的静态页面替代。

弹性伸缩

弹性伸缩包括弹性扩展和弹性收缩。弹性扩展，也就是流量压力大、服务响应时间变长时，自动化水平扩容，而弹性收缩指流量下降时能够自动减少节点数量，回收多余资源，节约平台占用的服务器总体成本。

总体而言，自动防御的思想精髓是“缓释”：即在入口处遮挡，同时在内部通过释放连接或者扩容等方式来恢复。

发布保障

1、使用工具进行自动化部署

2、分步分批与灰度发布：

应用程序部署并不等同于发布，部署指技术上线，发布是真正的业务上线，也就是放开流量。部署和发布，在操作上可能是连续一体的，但是存在巨大的含义差别，这里也是真正发布前的最后一道保障屏障。

核心思想是分步分批进行，先部署一部分节点（如10个节点选择2个），进行发布，也就是说承接流量，生产验证无误后，再部署发布其他节点。

灰度发布首先要圈定灰度单元格，灰度发布的核心，是对单元格所管理节点进行部署发布，称之为灰度生产环境，在流量入口处对流量来源进行逻辑区分（如使用请求头中的某个标识字段），将指定的流量引到灰度环境，以此进行生产验证，验证通过后，再部署发布全部节点。

3、让程序预热实现平滑上线

以JVM的运行方式来审视程序上线，可以发现问题：对上线节点放开流量时，如果处在业务高峰期，大量的访问请求进入新运行的程序，会导致同一时刻触发大量Class文件的JIT编译。

综上所述，发布应用时需要给节点一个预热过程，使其能够较为平顺地完成编译工作，方法可以是对于关键应用程序的上线工作，选择低流量时间段（一般是夜里），或者通过负载均衡来控制对新上线节点的流量分发，以阶梯状逐步增加，以便该节点有一个充分的预热过程。

应用高性能设计

对于高性能设计，重点从应用开发的视角来考虑。

异步、缓存、并行，是实现高性能体系的3个核心理念机制：

异步的效用可以从两方面看，一是让主功能不阻塞，尽快完成不受拖累，二是将串行转化为并行的处理方式；

缓存直接增加存取速度；

并行则是充分利用计算资源，同样的时间做更多的事情，重点指资源池、多线程、连接池、（分布式）多节点同时计算等技术运用。

热数据缓存：

介绍一个属于中台应用的性能优化方式——热数据缓存，以某网页的销售量排行榜为例，所有物品销售量时刻都在变化，没有办法事先准备数据，此类高频“热”数据，热力虽高，但其业务属性相对低（也就是持久化存储的必要性低），应考虑使用轻便的key-value型缓存库，也就是“不能让此类业务的客户查询请求，直接穿透到数据库中去查询”，从而实现极高的查询性能。有销量变化时，需要主动更新缓存，根据情况可以考虑非实时更新，无论如何，要保护数据库不受此类业务的冲击。

监控报警体系

平台监控能力建设属于“貌似简单、门槛较低，但是想要做好则上限极高”的那类任务。根本原因在于里面除技术外，存在长期的摸索过程、指标取舍和调试过程，需要在所有方面对系统十分了解，否则误报警、漏报警会不时发生。

1、主动轮询模式的监控

主动轮询模式的监控实际属于外挂型探活检测，外挂可以是测试团队做的发包器，在真实客户的网络环境下模拟客户请求。

如有预算，可以采购第三方拨测服务。

2、自动监控之业务监控

一般模式为对实时采集的业务监控日志的处理，通过预警指标系统进行报警。

3、自动监控之链路监控

一般有日志采集和进程探针两种模式：日志采集模式采集链路监控日志，针对其中日志ID的接口耗时时长，从技术角度对系统间调用链路进行分段监控，根据设定的链路时长指标阈值进行报警；

进程探针指在系统中埋拦截器，通过拦截器程序获取被观测点的时长等重要监控数据。

4、应用系统健康监控

健康监控模式包括两类：一是为每个应用系统均实现自检接口，二是在部分场景下，可以通过VRRP协议进行应用系统的心跳监听（Keepalived即如此）。

5、前端页面监控

在前端页面中加载监控脚本，记录页面加载和操作请求的响应速度，以及AJAX型请求和JavaScript脚本加载的时效和错误率，从而监控“页面加载时间、白屏率和白屏时间”等重要的用户端体验指标。

6、资源使用情况监控

这是最基础、最核心的监控方式，对于服务器、虚拟机、容器，监控项包括CPU和内存使用率、I/O吞吐量、带宽使用量、TCP连接数等。

可用率与容量衡量

平台能力衡量指标包括可用率、并发响应能力值，以及平台在数据、线路等方面的最大容量测算。

平台运行中最重要的高可用指标，即服务可用率，很多平台简称为SLA。

一套应用系统的SLA如果是99.9%，那么两套级联系统组成的单元的SLA是99.8%(99.9%×99.9%)，三套级联系统的SLA则是99.7%(99.9%×99.9%×99.9%)，印证了高性能部署提到的“纵深要浅、级联要少”的原则。

根据服务器（和操作系统）的可用率A、应用的可用率B，可计算出应用系统的SLA(A×B)。

使用了云技术之后，，第一，云资源服务器可用率高于自管理服务器可用率，也就是说A提升了；第二，云原生能力和微服务软件能力带来了应用层面的高可用提升，也就是说B提升了。

简言之，在保障A的基础上尽量提高B，使得实际运行的SLA结果值，不低于平台SLA的指标要求。

平台SLA的计算

容量衡量包括：用户容量、数据容量、线路容量。

行业里对注册用户数、在线用户数、并发用户数三者之间数量关系的认知是：

在线用户数=注册用户数×(5%～20%)

并发用户数=在线用户数×(5%～20%)

一个租户的数据量如果是100GB，而可以分配的数据存储表空间可用资源一共为10TB，那么最大租户量就是100个(10TB/100GB)。

考虑到数据库存储时的物理空间率利用问题，应该对租户的数据量进行一定比例的倍数放大，个人建议值为1.3～1.5倍。

线路容量，顾名思义是线路带宽能同时运输多少个业务请求。线路容量分为外部和内部，外部指互联网带宽，内部指局域网内部带宽。

并发性能衡量

QPS(Queries Per Second)，意思是每秒查询率，指某应用服务每秒能够响应的查询次数，用于衡量特定的查询服务器在规定时间内所处理流量的多少，主要针对专门用于查询的服务器的性能指标。

TPS(Transactions Per Second)，意思是每秒事务数。一个事务是指客户端向服务器发送请求后服务器做出反应的过程，具体的事务，可以是一个请求或是多个请求，并没有严格固定的定义。

TPS和QPS是客户端、服务端都可以通用的指标，但是在两者的定义中可以看到，TPS更适合描述客户端视角的指标，QPS更适合描述服务端视角的指标。

分布式之无状态

作为分布式的三驾马车，无状态应用、分布式事务和分布锁，是开发应用服务的必备选项。

无状态会话是当代分布式应用平台的典型特征之一，需要从全链条审视无状态设计，主要包括以下的切入点。

从服务端节点部署视角来看无状态会话:

应用系统节点之间是对等关系，与用户的SessionID及会话上下文信息彻底地解耦。

具体说就是用户的一次业务办理流程可能包括多次请求，前后步骤是串行关系，后一步的输入依赖前一步的结果，此时，如何实现负载可以将任意步骤的请求分发给应用系统的任何节点呢？对此唯一推荐的方案是：上下文信息内容脱离节点，放在可以高速读取的共享中间件处（如 Redis 处）。

从客户端与服务端交互视角来看无状态会话

务端不保存客户端状态，多数实现方式是服务端进行用户身份认证后，为用户生成某种会话凭证（即SessionID），例如，可以是Token令牌等。

从通信协议视角来看无状态会话

从客户端到服务端的每个请求都必须包含理解请求所需的所有信息，也就是“无状态API”，首先方案无疑是使用Http协议的Restful API.

用户便利性视角的无状态会话

使用统一身份认证实现用户单点登录是典型案例.

架构设计图

偏向中台和技术栈的分层架构示意图

偏重业务域的分层架构示意图

移动应用安全架构示意图

泳道风格交互流程示意图

反泳道风格交互流程示意图

立体风格交互流程示意图

立体风格逻辑关系示意图

分层次风格系统的逻辑关系示意图

应用系统部署设计示意图

数据主题处理关系示意图

数据分区分类设计示意图

罗列型的功能框架示意图

功能与交互混合型的功能框架示意图

前端技术评审表

后端技术评审表

版本发布台账

版本运行台账