阿里妹导读：架构师是一个既能掌控整体又能洞悉局部瓶颈并依据具体的业务场景给出解决方案的团队领导型人物。看似完美的“人格模型”背后，是艰辛的探索。今天，阿里巴巴技术专家九摩将多年经验，进行系统性地总结，帮助更多架构师在进阶这条路上走得更“顺畅”，姿态更“优雅”。
架构师职责
架构师不是一个人，他需要建立高效卓越的体系，带领团队去攻城略地，在规定的时间内完成项目。
架构师需要能够识别定义并确认需求，能够进行系统分解形成整体架构，能够正确地技术选型，能够制定技术规格说明并有效推动实施落地。
按 TOGAF 的定义，架构师的职责是了解并关注实际上关系重大但未变得过载的一些关键细节和界面，架构师的角色有：理解并解析需求，创建有用的模型，确认、细化并扩展模型，管理架构。
从业界来看对于架构师的理解可以大概区分为：
- 企业架构师：专注于企业总体 IT 架构的设计。
- IT 架构师-软件产品架构师：专注于软件产品的研发。
- IT 架构师-应用架构师：专注于结合企业需求，定制化 IT 解决方案；大部分需要交付的工作包括总体架构、应用架构、数据架构，甚至部署架构。
- IT 架构师-技术架构师：专注于基础设施，某种软硬件体系，甚至云平台，提交：产品建议、产品选型、部署架构、网络方案，甚至数据中心建设方案等。
阿里内部没有在职位 title 上专门设置架构师了，架构师更多是以角色而存在，现在还留下可见的 title 有两个：首席架构师和解决方案架构师，其中解决方案架构师目前在大部分 BU 都有设置，特别是在阿里云和电商体系。
自底向上推导应用架构
先根据业务流程，分解出系统时序图，根据时序图开始对模块进行归纳，从而得到粒度更大的模块，模块的组合／聚合构建整个系统架构。
基本上应用逻辑架构的推导有4个子路径，他们分别是：
- 业务概念架构：业务概念架构来自于业务概念模型和业务流程；
- 系统模型：来自于业务概念模型；
- 系统流程：来自业务流程；
- 非功能性的系统支撑：来自对性能、稳定性、成本的需要。
效率、稳定性、性能是最影响逻辑架构落地成物理架构的三大主要因素，所以从逻辑架构到物理架构，一定需要先对效率、稳定性和性能做出明确的量化要求。
自底向上重度依赖于演绎和归纳。
如果是产品方案已经明确，程序员需要理解这个业务需求，并根据产品方案推导出架构，此时一般使用自底向上的方法，而领域建模就是这种自底向上的分析方法。
对于自底向上的分析方法，如果提炼一下关键词，会得到如下两个关键词：
1.演绎：演绎就是逻辑推导，越是底层的，越需要演绎：
- 从用例到业务模型就属于演绎；
- 从业务模型到系统模型也属于演绎；
- 根据目前的问题，推导出要实施某种稳定性措施，这是也是演绎。
2.归纳：这里的归纳是根据事物的某个维度来进行归类，越是高层的，越需要归纳：
- 问题空间模块划分属于归纳；
- 逻辑架构中有部分也属于归纳；
- 根据一堆稳定性问题，归纳出，事前，事中，事后都需要做对应的操作，是就是根据时间维度来进行归纳。
3、领域划分，将所有识别出的实体对象进行分类；
4、评估域划分合理性，并进行优化。
基于数据驱动设计架构
随着 IoT、大数据和人工智能的发展，以领域驱动的方式进行架构往往满足不了需求或者达不到预期的效果，在大数据时代，在大数据应用场景，我们需要转变思维，从领域分析升维到基于大数据统计分析结果来进行业务架构、应用架构、数据架构和技术架构。这里需要架构师具备数理统计分析的基础和 BI 的能力，以数据思维来架构系统，典型的系统像阿里的数据分析平台采云间和菜鸟的数据分析平台 FBI。
上述四种思维，往往在架构设计中是融合使用的，需要根据业务或者系统的需求来选择侧重思维方式。
有了架构思维的指导，具体有没有通用／标准化的架构框架以更好的执行架构设计看常见的架构框架。下述的架构框架其实本身也包含了重要的一些架构思维。
常见架构框架
TOGAF
TOGAF 是 The Open Group Architecture Framework 的缩写，它由 The Open Group 开发，The Open Group 是一个非盈利的技术行业联盟，它不断更新和重申 TOGAF。
TOGAF 强调商业目标作为架构的驱动力，并提供了一个最佳实践的储藏库，其中包括 TOGAF 架构开发方法（ADM）、TOGAF 架构内容框架、TOGAF 参考模型、架构开发方法（ADM）指引和技术、企业连续统一体和 TOGAF 能力框架。
ADM
ADM是一个迭代的步骤顺序以发展企业范围的架构的方法。
参考模型
2、在不同水平运用ADM：
3、利益相关者分类：
（更多内容可以参考《TOGAF标准9.1版本》或者https://www.opengroup.org/togaf）
Zachman
第一个最有影响力的框架方法论就是 Zachman 框架，它是 John Zachman 首次在1987年提出的。
Zachman 框架模型分两个维度：横向维度采用6W（what、how、where、who、when、why）进行组织，纵向维度反映了 IT 架构层次，从上到下（Top-Down），分别为范围模型、企业模型、系统模型、技术模型、详细模型、功能模型。横向结合6W，Zachman 框架分别由数据、功能、网络、人员、时间、动机分别对应回答What、How、Where、Who、When 与 Why 这六个问题。
1.全景视点 AV
与所有视点相关的体系结构描述的顶层概貌。提供有关体系结构描述的总体信息，诸如体系结构描述的范围和背景。范围包括体系结构描述的专业领域和时间框架。背景由构成体系结构描述背景的相互关联各种条件组成，包括条令，战术、技术和程序，相关目标和构想的描述，作战概念(CONOPS)，想定和环境条件。
3.作战视点OV
作战视点(OV)集中反映了完成 DoD 使命的机构、任务或执行的行动以及彼此间必须交换的信息。描述信息交换的种类、频度、性质，信息交换支持哪些任务和活动。
5.系统视点 SV
系统视点(SV)集中反映支持作战行动中的自动化系统、相互交联和其他系统功能的信息。随着对面向服务环境和云计算的重视，在 DoDAF 的未来版本中也许不会有系统视点。
7.标准视点 StdV
标准视点(StdV)是用来管控系统各组成部分或要素的编排、交互和相互依赖的规则的最小集。其目的是确保系统能满足特定的一组操作需求。
标准视点提供技术系统的实施指南，以工程规范为基础，确立通用的积木块，开发产品线。
包括一系列技术标准、执行惯例、标准选项、规则和规范，这些标准在特定体系结构描述中可以组成管控系统和系统/服务要素的文件(profile)。
TOGAF，Zachman，ITSA 和 DODAF 是非常不错的架构框架，尤其前两者应用很广泛，TOGAF 还有专门的架构认证。当我们掌握了这些框架，我们是不是需要一些架构原则来指导更具体的设计看下文。
架构原则
设计原则就是架构设计的指导思想，它指导我们如何将数据和函数组织成类，如何将类链接起来成为组件和程序。反向来说，架构的主要工作就是将软件拆解为组件，设计原则指导我们如何拆解、拆解的粒度、组件间依赖的方向、组件解耦的方式等。
设计原则有很多，我们进行架构设计的主导原则是 OCP（开闭原则），在类和代码的层级上有：SRP（单一职责原则）、LSP（里氏替换原则）、ISP（接口隔离原则）、DIP（依赖反转原则）；在组件的层级上有：REP（复用、发布等同原则）、CCP（共同闭包原则）、CRP（共同复用原则），处理组件依赖问题的三原则：无依赖环原则、稳定依赖原则、稳定抽象原则。
1.OCP（开闭原则）：设计良好的软件应该易于扩展，同时抗拒修改。这是我们进行架构设计的主导原则，其他的原则都为这条原则服务。
2.SRP（单一职责原则）：任何一个软件模块，都应该有且只有一个被修改的原因，“被修改的原因“指系统的用户或所有者，翻译一下就是，任何模块只对一个用户的价值负责，该原则指导我们如何拆分组件。
举个例子，CTO 和 COO 都要统计员工的工时，当前他们要求的统计方式可能是相同的，我们复用一套代码，这时 COO 说周末的工时统计要乘以二，按照这个需求修改完代码，CTO 可能就要过来骂街了。当然这是个非常浅显的例子，实际项目中也有很多代码服务于多个价值主体，这带来很大的探秘成本和修改风险，另外，当一份代码有多个所有者时，就会产生代码合并冲突的问题。
3.LSP（里氏替换原则）：当用同一接口的不同实现互相替换时，系统的行为应该保持不变。该原则指导的是接口与其实现方式。
你一定很疑惑，实现了同一个接口，他们的行为也肯定是一致的呀，还真不一定。假设认为矩形的系统行为是：面积=宽*高，让正方形实现矩形的接口，在调用 setW 和 setH 时，正方形做的其实是同一个事情，设置它的边长。这时下边的单元测试用矩形能通过，用正方形就不行，实现同样的接口，但是系统行为变了，这是违反 LSP 的经典案例。
4.ISP（接口隔离原则）：不依赖任何不需要的方法、类或组件。该原则指导我们的接口设计。当我们依赖一个接口但只用到了其中的部分方法时，其实我们已经依赖了不需要的方法或类，当这些方法或类有变更时，会引起我们类的重新编译，或者引起我们组件的重新部署，这些都是不必要的。所以我们最好定义个小接口，把用到的方法拆出来。
5.DIP（依赖反转原则）：指一种特定的解耦（传统的依赖关系创建在高层次上，而具体的策略设置则应用在低层次的模块上）形式，使得高层次的模块不依赖于低层次的模块的实现细节，依赖关系被颠倒（反转），从而使得低层次模块依赖于高层次模块的需求抽象。
跨越组建边界的依赖方向永远与控制流的方向相反。该原则指导我们设计组件间依赖的方向。
依赖反转原则是个可操作性非常强的原则，当你要修改组件间的依赖方向时，将需要进行组件间通信的类抽象为接口，接口放在边界的哪边，依赖就指向哪边。
6.REP（复用、发布等同原则）：软件复用的最小粒度应等同于其发布的最小粒度。直白地说，就是要复用一段代码就把它抽成组件，该原则指导我们组件拆分的粒度。
7.CCP（共同闭包原则）：为了相同目的而同时修改的类，应该放在同一个组件中。CCP 原则是 SRP 原则在组件层面的描述。该原则指导我们组件拆分的粒度。
对大部分应用程序而言，可维护性的重要性远远大于可复用性，由同一个原因引起的代码修改，最好在同一个组件中，如果分散在多个组件中，那么开发、提交、部署的成本都会上升。
8.CRP（共同复用原则）：不要强迫一个组件依赖它不需要的东西。CRP 原则是 ISP原则在组件层面的描述。该原则指导我们组件拆分的粒度。
相信你一定有这种经历，集成了组件 A，但组件 A 依赖了组件 B、C。即使组件 B、C 你完全用不到，也不得不集成进来。这是因为你只用到了组件 A 的部分能力，组件 A 中额外的能力带来了额外的依赖。如果遵循共同复用原则，你需要把 A 拆分，只保留你要用的部分。
REP、CCP、CRP 三个原则之间存在彼此竞争的关系，REP 和 CCP 是黏合性原则，它们会让组件变得更大，而 CRP 原则是排除性原则，它会让组件变小。遵守REP、CCP 而忽略 CRP，就会依赖了太多没有用到的组件和类，而这些组件或类的变动会导致你自己的组件进行太多不必要的发布；遵守 REP、CRP 而忽略 CCP，因为组件拆分的太细了，一个需求变更可能要改 n 个组件，带来的成本也是巨大的。
除了上述设计原则，还有一些重要的指导原则如下：
特征：应用程序，数据库，文件等所有资源都放在一台服务器上。
应用服务和数据服务以及文件服务分离
说明：系统访问特点遵循二八定律，即80%的业务访问集中在20%的数据上。缓存分为本地缓存 远程分布式缓存，本地缓存访问速度更快但缓存数据量有限，同时存在与应用程序争用内存的情况。
特征：数据库中访问较集中的一小部分数据存储在缓存服务器中，减少数据库的访问次数，降低数据库的访问压力。
使用“应用服务器”集群
说明：享受了一段时间的系统访问量高速增长的幸福后，发现系统又开始变慢了，这次又是什么状况呢，经过查找，发现数据库写入、更新的这些操作的部分数据库连接的资源竞争非常激烈，导致了系统变慢。
特征：数据库引入主备部署。
描述：把数据库划分为读库和写库，通过引入主从数据库服务，读和写操作在不同的数据库服务处理，读库可以有多个，通过同步机制把写库的数据同步到读库，对于需要查询最新写入数据场景，可以通过在缓存中多写一份，通过缓存获得最新数据。
反向代理和CDN加速
说明：随着系统的不断运行，数据量开始大幅度增长，这个时候发现分库后查询仍然会有些慢，于是按照分库的思想开始做分表的工作
特征：数据库采用分布式数据库，文件系统采用分布式文件系统。
描述：任何强大的单一服务器都满足不了大型系统持续增长的业务需求，数据库读写分离随着业务的发展最终也将无法满足需求，需要使用分布式数据库及分布式文件系统来支撑。
分布式数据库是系统数据库拆分的最后方法，只有在单表数据规模非常庞大的时候才使用，更常用的数据库拆分手段是业务分库，将不同的业务数据库部署在不同的物理服务器上。
使用 NoSQL 和搜索引擎
特征：系统上按照业务进行拆分改造，应用服务器按照业务区分进行分别部署。
描述：为了应对日益复杂的业务场景，通常使用分而治之的手段将整个系统业务分成不同的产品线，应用之间通过超链接建立关系，也可以通过消息队列进行数据分发，当然更多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。
纵向拆分：将一个大应用拆分为多个小应用，如果新业务较为独立，那么就直接将其设计部署为一个独立的 Web 应用系统纵向拆分相对较为简单，通过梳理业务，将较少相关的业务剥离即可。
横向拆分：将复用的业务拆分出来，独立部署为分布式服务，新增业务只需要调用这些分布式服务横向拆分需要识别可复用的业务，设计服务接口，规范服务依赖关系。
分布式服务
在单元化架构下，服务虽然分层划分，但每个单元自成一体。按照层次来讲的话，所有层使用相同的分区算法，每一层都有相同数量的节点，上层节点也会访问指定的下层节点。
SOA架构
SOA（Service-Oriented Architecture，面向服务的架构）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。面向服务架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是 SOA 的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。
SOA的实施具有几个鲜明的基本特征。实施 SOA 的关键目标是实现企业 IT 资产的最大化作用。要实现这一目标，就要在实施 SOA 的过程中牢记以下特征：
（1）可从企业外部访问
（2）随时可用
（3）粗粒度的服务接口分级
（4）松散耦合
（5）可重用的服务
（6）服务接口设计管理
（7）标准化的服务接口
（8）支持各种消息模式
（9）精确定义的服务契约为了实现 SOA，企业需要一个服务架构，下图显示了一个例子：
优点：
- 开发简单，集中式管理；
- 基本不会重复开发；
- 功能都在本地，没有分布式的管理和调用消耗。
缺点：
- 效率低：开发都在同一个项目改代码，相互等待，冲突不断；
- 维护难：代码功功能耦合在一起，新人不知道何从下手；
- 不灵活：构建时间长，任何小修改都要重构整个项目，耗时；
- 稳定性差：一个微小的问题，都可能导致整个应用挂掉；
- 扩展性不够：无法满足高并发下的业务需求。
常见的系统架构遵循的三个标准和业务驱动力：
- 提高敏捷性：及时响应业务需求，促进企业发展；
- 提升用户体验：提升用户体验，减少用户流失；
- 降低成本：降低增加产品、客户或业务方案的成本。
基于微服务架构的设计：
目的：有效的拆分应用，实现敏捷开发和部署。
- X轴：运行多个负载均衡器之后的运行实例；
- Y轴：将应用进一步分解为微服务（分库）；
- Z轴：大数据量时，将服务分区（分表）。
SOA和微服务的区别：
- SOA喜欢重用，微服务喜欢重写；
- SOA喜欢水平服务，微服务喜欢垂直服务；
- SOA喜欢自上而下，微服务喜欢自下而上。
Serverless 架构
1、思想：无服务器是一种架构理念，其核心思想是将提供服务资源的基础设施抽象成各种服务，以 API 接口的方式供给用户按需调用，真正做到按需伸缩、按使用收费。
2、优势：消除了对传统的海量持续在线服务器组件的需求，降低了开发和运维的复杂性，降低运营成本并缩短了业务系统的交付周期，使得用户能够专注在价值密度更高的业务逻辑的开发上。
3、内容：目前业界较为公认的无服务器架构主要包括两个方面，即提供计算资源的函数服务平台 FaaS，以及提供托管云服务的后端服务 BaaS。
函数即服务（Function as a Service）：是一项基于事件驱动的函数托管计算服务。通过函数服务，开发者只需要编写业务函数代码并设置运行的条件，无需配置和管理服务器等基础设施，函数代码运行在无状态的容器中，由事件触发且短暂易失，并完全由第三方管理，基础设施对应用开发者完全透明。函数以弹性、高可靠的方式运行，并且按实际执行资源计费，不执行不产生费用。
后端即服务（Backend as a Service）：BaaS 覆盖了应用可能依赖的所有第三方服务，如云数据库、身份验证、对象存储等服务，开发人员通过 API 和由 BaaS 服务商提供的 SDK，能够集成所需的所有后端功能，而无需构建后端应用，更不必管理虚拟机或容器等基础设施，就能保证应用的正常运行。
架构结果管理
参考资料：
https://developer.alipay.com/article/8538
https://www.cnblogs.com/wintersun/p/8972949.html
https://www.atatech.org/articles/95466
https://www.atatech.org/articles/104688
https://yuque.antfin-inc.com/tmf/documents/how-to-desigin-domain声明：本文部分内容参考阿里内部和外部一些文章，详情见上述参考资料；撰写本文的重点是系统体系化地总结认识架构师的工作，以便于更好的互动学习和成长，部分观点是个人观点。
原文发布时间为： 2019-07-3
本文作者： 九摩
本文来自云栖社区合作伙伴“ 阿里技术”，了解相关信息可以关注“ 阿里技术”。来源：十年磨一行
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！