如何带领团队“攻城略地”？优秀的架构师这样作

架构师职责

架构师不是一我的，他须要创建高效卓越的体系，带领团队去攻城略地，在规定的时间内完成项目。

架构师须要可以识别定义并确认需求，可以进行系统分解造成总体架构，可以正确地技术选型，可以制定技术规格说明并有效推进实施落地。

按 TOGAF 的定义，架构师的职责是了解并关注实际上关系重大但未变得过载的一些关键细节和界面，架构师的角色有：理解并解析需求，建立有用的模型，确认、细化并扩展模型，管理架构。

从业界来看对于架构师的理解能够大概区分为：

• 企业架构师：专一于企业整体 IT 架构的设计。
• IT 架构师-软件产品架构师：专一于软件产品的研发。
• IT 架构师-应用架构师：专一于结合企业需求，定制化 IT 解决方案；大部分须要交付的工做包括整体架构、应用架构、数据架构，甚至部署架构。
• IT 架构师-技术架构师：专一于基础设施，某种软硬件体系，甚至云平台，提交：产品建议、产品选型、部署架构、网络方案，甚至数据中心建设方案等。

阿里内部没有在职位 title 上专门设置架构师了，架构师更可能是以角色而存在，如今还留下可见的 title 有两个：首席架构师和解决方案架构师，其中解决方案架构师目前在大部分 BU 都有设置，特别是在阿里云和电商体系。

解决方案架构师

工做方式理解

• 了解和挖掘客户痛点，项目定义，现有环境管理；
• 梳理明确高阶需求和非功能性需求；
• 客户有什么资产，星环（阿里电商操做系统）／阿里云等有什么解决方案；
• 沟通，方案建议，屡次迭代，交付整体架构；
• 架构决策。

职责

1.从客户视图来看：

• 坚决客户高层信心：利用架构和解决方案能力，帮忙客户选择星环／阿里云平台的信心。
• 解决客户中层问题：利用星环／阿里云平台服务+结合应用架构设计/解决方案能力，帮忙客户解决业务问题，得到业务价值。
• 引领客户 IT 员工和阿里生态同窗：技术引领、方法引领、产品引领。

2.从项目视图看：

• 对接管理部门：汇报技术方案，进度；技术沟通。
• 对接客户 PM，项目 PM：协助项目计划，人员管理等。负责全部技术交付物的指导。
• 对接业务部门和需求人员：了解和挖掘痛点，帮忙梳理高级业务需求，指导需求工艺。
• 对接开发：产品支持、技术指导、架构指导。
• 对接测试：配合测试计划和工艺制定。配合性能测试或者非功能性测试。
• 对接运维：产品支持，运维支持。
• 对接配置&环境：产品支持。
• 其余：阿里技术资源聚合。

3.从阿里内部看：

• 销售方案支持；
• 市场宣贯；
• 客户需求Facade；
• 解决方案沉淀。

架构师职责明确了，那么有什么架构思惟能够指导架构设计呢？请看下述的架构思惟。

架构思惟

自顶向下构建架构

要点主要以下：

1.首先定义问题，而定义问题中最重要的是定义客户的问题。定义问题，特别是识别出关键问题，关键问题是对客户有体感，可以解决客户痛点，经过必定的数据化来衡量识别出来，关键问题要优先给出解决方案。

2.问题定义务必加入时间维度，把手段/方案和问题定义区分开来。

3.问题定义中，须要对问题进行升层思考后再进行升维思考，从而真正抓到问题的本质，理清和挖掘清楚需求；要善用第一性原理思惟进行分析思考问题。

4.问题解决原则：先解决客户的问题（使命），而后才能解决本身的问题（愿景）；务必记住不是强调咱们怎么样，而是咱们能为客户具体解决什么问题，而后才是咱们变成什么，从而怎么样去更好得服务客户。

5.善用多种方法对客户问题进行分析，转换成咱们产品或者平台须要提供的能力，好比仓储系统 WMS 能够提供哪些商业能力。

6.对咱们的现有的流程和能力模型进行梳理，找到须要提高的地方，升层思考和升维思考真正明确提高部分。

7.定义指标，并可以对指标进行拆解，而后进行数学建模。

8.将抽象出来的能力诉求转换成技术挑战，此步对于技术人员来讲至关于找到了靶子，能够进行方案的设计了，须要结合自底向上的架构推导方式。

9.创新能够是业务创新，也能够是产品创新，也能够是技术创新，也能够是运营创新，升层思考、升维思考，使用第一性原理思惟、生物学（进化论--进化=变异+选择+隔离、熵增定律、分形和涌现）思惟等哲科思惟能够帮助咱们在业务，产品，技术上发现不一样的创新可能。能够说哲科思惟是架构师的灵魂思惟。

自底向上推导应用架构

先根据业务流程，分解出系统时序图，根据时序图开始对模块进行概括，从而获得粒度更大的模块，模块的组合／聚合构建整个系统架构。

基本上应用逻辑架构的推导有4个子路径，他们分别是：

1. 业务概念架构：业务概念架构来自于业务概念模型和业务流程；
2. 系统模型：来自于业务概念模型；
3. 系统流程：来自业务流程；
4. 非功能性的系统支撑：来自对性能、稳定性、成本的须要。

效率、稳定性、性能是最影响逻辑架构落地成物理架构的三大主要因素，因此从逻辑架构到物理架构，必定须要先对效率、稳定性和性能作出明确的量化要求。

自底向上重度依赖于演绎和概括。

若是是产品方案已经明确，程序员须要理解这个业务需求，并根据产品方案推导出架构，此时通常使用自底向上的方法，而领域建模就是这种自底向上的分析方法。

对于自底向上的分析方法，若是提炼一下关键词，会获得以下两个关键词：

1.演绎：演绎就是逻辑推导，越是底层的，越须要演绎：

• 从用例到业务模型就属于演绎；
• 从业务模型到系统模型也属于演绎；
• 根据目前的问题，推导出要实施某种稳定性措施，这是也是演绎。

2.概括：这里的概括是根据事物的某个维度来进行归类，越是高层的，越须要概括：

• 问题空间模块划分属于概括；
• 逻辑架构中有部分也属于概括；
• 根据一堆稳定性问题，概括出，事前，事中，过后都须要作对应的操做，是就是根据时间维度来进行概括。

领域驱动设计架构

大部分传统架构都是基于领域模型分析架构，典型的领域实现模型设计能够参考DDD（领域驱动设计），详细能够参考《实现领域驱动设计》这本书，另外《UML和模式应用》在领域建模实操方面比较好，前者偏理论了解，后者便于落地实践。

领域划分设计步骤：

1.对用户需求场景分析，识别出业务全维度 Use Case；

2.分析模型鲁棒图，识别出业务场景中全部的实体对象。鲁棒图 —— 是需求设计过程当中使用的一种方法（鲁棒性分析），经过鲁棒分析法可让设计人员更清晰，更全面地了解需求。它一般使用在需求分析后及需求设计前作软件架构分析之用，它主要注重于功能需求的设计分析工做。需求规格说明书为其输入信息，设计模型为其输出信息。它是从功能需求向设计方案过渡的第一步，重点是识别组成软件系统的高级职责模块、规划模块之间的关系。鲁棒图包含三种图形：边界、控制、实体，三个图形以下：

三、领域划分，将全部识别出的实体对象进行分类；

四、评估域划分合理性，并进行优化。

基于数据驱动设计架构

随着 IoT、大数据和人工智能的发展，以领域驱动的方式进行架构每每知足不了需求或者达不到预期的效果，在大数据时代，在大数据应用场景，咱们须要转变思惟，从领域分析升维到基于大数据统计分析结果来进行业务架构、应用架构、数据架构和技术架构。这里须要架构师具有数理统计分析的基础和 BI 的能力，以数据思惟来架构系统，典型的系统像阿里的数据分析平台采云间和菜鸟的数据分析平台 FBI。

上述四种思惟，每每在架构设计中是融合使用的，须要根据业务或者系统的需求来选择侧重思惟方式。

有了架构思惟的指导，具体有没有通用／标准化的架构框架以更好的执行架构设计？请看常见的架构框架。下述的架构框架其实自己也包含了重要的一些架构思惟。

推荐一个Java高级技术进阶群：976203838，文章运用到的架构技术都会在群里分享，都能免费下载。有兴趣学习的猿猿能够加一下。

常见架构框架

TOGAF

TOGAF 是 The Open Group Architecture Framework 的缩写，它由 The Open Group 开发，The Open Group 是一个非盈利的技术行业联盟，它不断更新和重申 TOGAF。

TOGAF 强调商业目标做为架构的驱动力，并提供了一个最佳实践的储藏库，其中包括 TOGAF 架构开发方法（ADM）、TOGAF 架构内容框架、TOGAF 参考模型、架构开发方法（ADM）指引和技术、企业连续统一体和 TOGAF 能力框架。

ADM

ADM是一个迭代的步骤顺序以发展企业范围的架构的方法。

架构内容框架

参考模型

ADM指引和技术

一、架构迭代阶段：

二、在不一样水平运用ADM：

三、利益相关者分类：

企业连续统一体

架构指导及支持解决方案：基础 通用系统 行业组织特定

能力框架

（更多内容能够参考《TOGAF标准9.1版本》或者

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 这六个问题。

ITSA

ITSA诞生于1986年的惠普，世界最先的企业架构框架(IT战略与架构)。建模原则就是“Everything you need, and nothing you don’t”，只放你要的东西。

DODAF

DODAF 是美国国防部架构框架，是一个控制“EA开发、维护和决策生成”的组织机制，是统一组织“团队资源、描述和控制EA活动”的整体结构。

DODAF 涵盖 DoD 的全部业务领域，定义了表示、描述、集成 DoD 范围内众多架构的标准方法，确保架构描述可比较、评估，提供了对 FoS (系统族)和 SoS (体系)进行理解、比较、集成和互操做共同的架构基础，提供开发和表达架构描述的规则和指南,但不指导如何实现。

DODAF 核心是8个视点和52个模型。

1.全景视点 AV

与全部视点相关的体系结构描述的顶层概貌。提供有关体系结构描述的整体信息，诸如体系结构描述的范围和背景。范围包括体系结构描述的专业领域和时间框架。背景由构成体系结构描述背景的相互关联各类条件组成，包括条令，战术、技术和程序，相关目标和构想的描述，做战概念(CONOPS)，想定和环境条件。

2.能力视点CV

能力视点(CV)集中反映了与总体愿景相关的组织目标，这些愿景指在特定标准和条件下进行特定行动过程或是达成指望效果的能力，它们综合使用各类手段和方式来完成一组任务。

CV 为体系结构描述中阐述的能力提供了战略背景和相应的高层范围，比做战概念图中定义的基于想定的范围更全面。

这些模型是高层的，用决策者易于理解的术语来描述能力，以便沟通能力演进方面战略构想。

3.做战视点OV

做战视点(OV)集中反映了完成 DoD 使命的机构、任务或执行的行动以及彼此间必须交换的信息。描述信息交换的种类、频度、性质，信息交换支持哪些任务和活动。

4.服务视点 SvcV

服务视点(SvcV)集中反映了为做战行动提供支撑的系统、服务和相互交织的功能。DoD 流程包括做战、业务、情报和基础设施功能。SvcV 功能和服务资源及要素能够连接到 0V 中的体系结构数据。这些系统功能和服务资源支撑做战行动，促进信息交换。

5.系统视点 SV

系统视点(SV)集中反映支持做战行动中的自动化系统、相互交联和其余系统功能的信息。随着对面向服务环境和云计算的重视，在 DoDAF 的将来版本中也许不会有系统视点。

6.数信视点 DIV

数据和信息视点(DIV)，简称数信视点，反映了体系结构描述中的业务信息需求和结构化的业务流程规则。

描述体系结构描述中与信息交换相关的信息，诸如属性、特征和相互关系。
必要时，本视点模型中用到的数据须要由多个架构团队来共同考虑。

7.标准视点 StdV

标准视点(StdV)是用来管控系统各组成部分或要素的编排、交互和相互依赖的规则的最小集。其目的是确保系统能知足特定的一组操做需求。

标准视点提供技术系统的实施指南，以工程规范为基础，确立通用的积木块，开发产品线。

包括一系列技术标准、执行惯例、标准选项、规则和规范，这些标准在特定体系结构描述中能够组成管控系统和系统/服务要素的文件(profile)。

8.项目视点 PV

项目视点(PV)集中反映了项目是如何有机地组织成一个釆办项目的有序组合。
描述多个采办项目之间关联关系，每一个采办项目都负责交付特定系统或能力。

TOGAF，Zachman，ITSA 和 DODAF 是很是不错的架构框架，尤为前二者应用很普遍，TOGAF 还有专门的架构认证。当咱们掌握了这些框架，咱们是否是须要一些架构原则来指导更具体的设计？请看下文。

推荐一个Java高级技术进阶群：976203838，文章运用到的架构技术都会在群里分享，都能免费下载。有兴趣学习的猿猿能够加一下。

架构原则

设计原则就是架构设计的指导思想，它指导咱们如何将数据和函数组织成类，如何将类连接起来成为组件和程序。反向来讲，架构的主要工做就是将软件拆解为组件，设计原则指导咱们如何拆解、拆解的粒度、组件间依赖的方向、组件解耦的方式等。

设计原则有不少，咱们进行架构设计的主导原则是 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 个组件，带来的成本也是巨大的。

除了上述设计原则，还有一些重要的指导原则以下：

1.N+1设计：系统中的每一个组件都应作到没有单点故障；

2.回滚设计：确保系统能够向前兼容，在系统升级时应能有办法回滚版本；

3.禁用设计：应该提供控制具体功能是否可用的配置，在系统出现故障时可以快速下线功能；

4.监控设计：在设计阶段就要考虑监控的手段，便于有效的排查问题，好比引入traceId、业务身份 Id 便于排查监控问题；

5.多活数据中心设计：若系统须要极高的高可用，应考虑在多地实施数据中心进行多活，至少在一个机房断电的状况下系统依然可用；

6.采用成熟的技术：刚开发的或开源的技术每每存在不少隐藏的 bug，出了问题没有很好的商业支持可能会是一个灾难；

7.资源隔离设计：应避免单一业务占用所有资源；

8.架构水平扩展设计：系统只有作到能水平扩展，才能有效避免瓶颈问题；

9.非核心则购买的原则：非核心功能若须要占用大量的研发资源才能解决，则考虑购买成熟的产品；

10.使用商用硬件：商用硬件能有效下降硬件故障的机率；

11.快速迭代：系统应该快速开发小功能模块，尽快上线进行验证，早日发现问题大大下降系统交付的风险；

12.无状态设计：服务接口应该作成无状态的，当前接口的访问不依赖于接口上次访问的状态。

架构师知道了职责，具有很好的架构思惟，掌握了通用的架构框架和方法论，使用架构原则进行架构设计，不一样的业务和系统要求不同，那么有没有针对不一样场景的系统架构设计？下文就针对分布式架构演进、单元化架构、面向服务 SOA 架构、微服务架构、Serverless 架构进行介绍，以便于咱们在实际运用中进行参考使用。

常见架构

分布式架构演进

初始阶段架构

特征：应用程序，数据库，文件等全部资源都放在一台服务器上。

应用服务和数据服务以及文件服务分离

说明：好景不长，发现随着系统访问量的再度增长，webserver 机器的压力在高峰期会上升到比较高，这个时候开始考虑增长一台 webserver。

特征：应用程序、数据库、文件分别部署在独立的资源上。

使用缓存改善性能

说明：系统访问特色遵循二八定律，即80%的业务访问集中在20%的数据上。缓存分为本地缓存 远程分布式缓存，本地缓存访问速度更快但缓存数据量有限，同时存在与应用程序争用内存的状况。

特征：数据库中访问较集中的一小部分数据存储在缓存服务器中，减小数据库的访问次数，下降数据库的访问压力。

使用“应用服务器”集群

说明：在作完分库分表这些工做后，数据库上的压力已经降到比较低了，又开始过着天天看着访问量暴增的幸福生活了。忽然有一天，发现系统的访问又开始有变慢的趋势了，这个时候首先查看数据库，压力一切正常，以后查看 webserver，发现apache 阻塞了不少的请求， 而应用服务器对每一个请求也是比较快的，看来是请求数过高致使须要排队等待，响应速度变慢。

特征：多台服务器经过负载均衡同时向外部提供服务，解决单台服务器处理能力和存储空间上限的问题。

描述：使用集群是系统解决高并发、海量数据问题的经常使用手段。经过向集群中追加资源，提高系统的并发处理能力，使得服务器的负载压力再也不成为整个系统的瓶颈。

数据库读写分离

说明：享受了一段时间的系统访问量高速增加的幸福后，发现系统又开始变慢了，此次又是什么情况呢，通过查找，发现数据库写入、更新的这些操做的部分数据库链接的资源竞争很是激烈，致使了系统变慢。

特征：数据库引入主备部署。

描述：把数据库划分为读库和写库，经过引入主从数据库服务，读和写操做在不一样的数据库服务处理，读库能够有多个，经过同步机制把写库的数据同步到读库，对于须要查询最新写入数据场景，能够经过在缓存中多写一份，经过缓存得到最新数据。

反向代理和CDN加速

特征：采用CDN和反向代理加快系统的访问速度。

描述：为了应付复杂的网络环境和不一样地区用户的访问，经过 CDN 和反向代理加快用户访问的速度，同时减轻后端服务器的负载压力。CDN 与反向代理的基本原理都是缓存。

“分布式文件”系统 和 “分布式数据库”

说明：随着系统的不断运行，数据量开始大幅度增加，这个时候发现分库后查询仍然会有些慢，因而按照分库的思想开始作分表的工做

特征：数据库采用分布式数据库，文件系统采用分布式文件系统。

描述：任何强大的单一服务器都知足不了大型系统持续增加的业务需求，数据库读写分离随着业务的发展最终也将没法知足需求，须要使用分布式数据库及分布式文件系统来支撑。

分布式数据库是系统数据库拆分的最后方法，只有在单表数据规模很是庞大的时候才使用，更经常使用的数据库拆分手段是业务分库，将不一样的业务数据库部署在不一样的物理服务器上。

使用 NoSQL 和搜索引擎

特征：系统引入 NoSQL 数据库及搜索引擎。

描述：随着业务愈来愈复杂，对数据存储和检索的需求也愈来愈复杂，系统须要采用一些非关系型数据库如 NoSQL 和分数据库查询技术如搜索引擎。

应用服务器经过统一数据访问模块访问各类数据，减轻应用程序管理诸多数据源的麻烦。

业务拆分

特征：系统上按照业务进行拆分改造，应用服务器按照业务区分进行分别部署。

描述：为了应对日益复杂的业务场景，一般使用分而治之的手段将整个系统业务分红不一样的产品线，应用之间经过超连接创建关系，也能够经过消息队列进行数据分发，固然更多的仍是经过访问同一个数据存储系统来构成一个关联的完整系统。

纵向拆分：将一个大应用拆分为多个小应用，若是新业务较为独立，那么就直接将其设计部署为一个独立的 Web 应用系统纵向拆分相对较为简单，经过梳理业务，将较少相关的业务剥离便可。

横向拆分：将复用的业务拆分出来，独立部署为分布式服务，新增业务只须要调用这些分布式服务横向拆分须要识别可复用的业务，设计服务接口，规范服务依赖关系。

分布式服务

特征：公共的应用模块被提取出来，部署在分布式服务器上供应用服务器调用。

描述：随着业务越拆越小，应用系统总体复杂程度呈指数级上升，因为全部应用要和全部数据库系统链接，最终致使数据库链接资源不足，拒绝服务。

分布式服务的问题和挑战：

(1) 当服务愈来愈多时，服务URL配置管理变得很是困难，F5硬件负载均衡器的单点压力也愈来愈大。

(2) 当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪一个应用要在哪一个应用以前启动，架构师都不能完整的描述应用的架构关系。

(3) 服务的调用量愈来愈大，服务的容量问题就暴露出来，这个服务须要多少机器支撑？何时该加机器？

(4) 服务多了，沟通成本也开始上升，调某个服务失败该找谁？服务的参数都有什么约定？

(5) 一个服务有多个业务消费者，如何确保服务质量？

(6) 随着服务的不停升级，总有些意想不到的事发生，好比 cache 写错了致使内存溢出，故障不可避免，每次核心服务一挂，影响一大片，人心慌慌，如何控制故障的影响面？服务是否能够功能降级？或者资源劣化？

针对这些问题，下述的单元化架构，微服务架构以及 Serveless 架构能够必定程度解决，另外针对业务系统，须要作到业务与业务隔离、管理域和运行域分开、业务与平台隔离方可解决上述问题。

单元化架构

一、什么是单元化：单元化架构是从并行计算领域发展而来。在分布式服务设计领域，一个单元（Cell）就是知足某个分区全部业务操做的自包含的安装。而一个分区（Shard），则是总体数据集的一个子集，若是你用尾号来划分用户，那一样尾号的那部分用户就能够认为是一个分区。单元化就是将一个服务设计改造让其符合单元特征的过程。

二、单元化的必要性：随着硬件的不断升级，计算机硬件能力已经愈来愈强，CPU愈来愈快，内存愈来愈大，网络愈来愈宽。这让咱们看到了在单台机器上垂直扩展的机会。尤为是当你遇到一个性能要求和容量增加能够预期的业务，单元化给咱们提供另外的机会，让咱们能够有效下降资源的使用，提供更高性能的服务。

更高性能更低成本是咱们的主要目标，通过单元化改造，咱们得以用更少（约二分之一）的机器，得到了比原来更高（接近百倍）的性能。性能的提高很大部分缘由在于服务的本地化，而服务的集成部署又进一步下降了资源的使用。除了性能收益，还有不少收益，好比更好的隔离性，包括请求隔离和资源隔离，好比更友好的升级，产品能够灰度发布等。单元化改造后对高峰的应对以及扩容方式等问题的解决。

三、如何作到单元化：先看下图传统的服务架构，服务是分层的，每一层使用不一样的分区算法，每一层都有不一样数量的节点，上层节点随机选择下层节点。

在单元化架构下，服务虽然分层划分，但每一个单元自成一体。按照层次来说的话，全部层使用相同的分区算法，每一层都有相同数量的节点，上层节点也会访问指定的下层节点。

SOA架构

SOA（Service-Oriented Architecture，面向服务的架构）是一个组件模型，它将应用程序的不一样功能单元（称为服务）经过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操做系统和编程语言。这使得构建在各类各样的系统中的服务能够以一种统一和通用的方式进行交互。面向服务架构，它能够根据需求经过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是 SOA 的基础，能够直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。

SOA的实施具备几个鲜明的基本特征。实施 SOA 的关键目标是实现企业 IT 资产的最大化做用。要实现这一目标，就要在实施 SOA 的过程当中牢记如下特征：

（1）可从企业外部访问
（2）随时可用
（3）粗粒度的服务接口分级
（4）松散耦合
（5）可重用的服务
（6）服务接口设计管理
（7）标准化的服务接口
（8）支持各类消息模式
（9）精肯定义的服务契约

为了实现 SOA，企业须要一个服务架构，下图显示了一个例子：

在上图中， 服务消费者（service consumer）能够经过发送消息来调用服务。这些消息由一个服务总线（service bus）转换后发送给适当的服务实现。这种服务架构能够提供一个业务规则引（business rules engine），该引擎允许业务规则被合并在一个服务里或多个服务里。这种架构也提供了一个服务管理基础（service management infrastructure），用来管理服务，相似审核，列表（billing），日志等功能。此外，该架构给企业提供了灵活的业务流程，更好地处理控制请求（regulatory requirement），例如Sarbanes Oxley（SOX），而且能够在不影响其余服务的状况下更改某项服务。

推荐一个Java高级技术进阶群：976203838，文章运用到的架构技术都会在群里分享，都能免费下载。有兴趣学习的猿猿能够加一下。

微服务架构

先来看看传统的 web 开发方式，经过对比比较容易理解什么是 Microservice Architecture。和 Microservice 相对应的，这种方式通常被称为 Monolithic（单体式开发）。

全部的功能打包在一个 WAR包里，基本没有外部依赖（除了容器），部署在一个JEE容器（Tomcat，JBoss，WebLogic）里，包含了 DO/DAO，Service，UI 等全部逻辑。

优势：

• 开发简单，集中式管理；
• 基本不会重复开发；
• 功能都在本地，没有分布式的管理和调用消耗。

缺点：

• 效率低：开发都在同一个项目改代码，相互等待，冲突不断；
• 维护难：代码功功能耦合在一块儿，新人不知道何从下手；
• 不灵活：构建时间长，任何小修改都要重构整个项目，耗时；
• 稳定性差：一个微小的问题，均可能致使整个应用挂掉；
• 扩展性不够：没法知足高并发下的业务需求。

常见的系统架构遵循的三个标准和业务驱动力：

• 提升敏捷性：及时响应业务需求，促进企业发展；
• 提高用户体验：提高用户体验，减小用户流失；
• 下降成本：下降增长产品、客户或业务方案的成本。

基于微服务架构的设计：

目的：有效的拆分应用，实现敏捷开发和部署。

关于微服务的一个形象表达：

• X轴：运行多个负载均衡器以后的运行实例；
• Y轴：将应用进一步分解为微服务（分库）；
• Z轴：大数据量时，将服务分区（分表）。

SOA和微服务的区别：

• SOA喜欢重用，微服务喜欢重写；
• SOA喜欢水平服务，微服务喜欢垂直服务；
• SOA喜欢自上而下，微服务喜欢自下而上。

Serverless 架构

一、思想：无服务器是一种架构理念，其核心思想是将提供服务资源的基础设施抽象成各类服务，以 API 接口的方式供给用户按需调用，真正作到按需伸缩、按使用收费。

二、优点：消除了对传统的海量持续在线服务器组件的需求，下降了开发和运维的复杂性，下降运营成本并缩短了业务系统的交付周期，使得用户可以专一在价值密度更高的业务逻辑的开发上。

三、内容：目前业界较为公认的无服务器架构主要包括两个方面，即提供计算资源的函数服务平台 FaaS，以及提供托管云服务的后端服务 BaaS。

函数即服务（Function as a Service）：是一项基于事件驱动的函数托管计算服务。经过函数服务，开发者只须要编写业务函数代码并设置运行的条件，无需配置和管理服务器等基础设施，函数代码运行在无状态的容器中，由事件触发且短暂易失，并彻底由第三方管理，基础设施对应用开发者彻底透明。函数以弹性、高可靠的方式运行，而且按实际执行资源计费，不执行不产生费用。

后端即服务（Backend as a Service）：BaaS 覆盖了应用可能依赖的全部第三方服务，如云数据库、身份验证、对象存储等服务，开发人员经过 API 和由 BaaS 服务商提供的 SDK，可以集成所需的全部后端功能，而无需构建后端应用，更没必要管理虚拟机或容器等基础设施，就能保证应用的正常运行。

三个less感受很好：

• Codeless 对应的是服务开发，实现了源代码托管，你只须要关注你的代码实现，而不须要关心你的代码在哪，由于在整个开发过程当中你都不会感觉到代码库和代码分支的存在。
• Applicationless 对应的是服务发布，在服务化框架下，你的服务发布再也不须要申请应用，也不须要关注你的应用在哪。
• Serverless 对应的则是服务运维，有了 Serverless 化能力，你再也不须要关注你的机器资源，Servlerless 会帮你搞定机器资源的弹性扩缩容。

架构师在完成上述架构设计后，最终是须要协同利益相关方一块儿按项目化运做落地拿结果，那么应该如何保证利益相关方在项目落地的满意度，如何保证按照架构很好的拿到项目成功的结果呢？架构管理能力是架构师很是重要的能力。

架构管理

架构双赢模型

架构结果管理

参考资料：

developer.alipay.com/article/853…
www.cnblogs.com/wintersun/p…
www.atatech.org/articles/95…
www.atatech.org/articles/10…
yuque.antfin-inc.com/tmf/documen…

声明：本文部份内容参考阿里内部和外部一些文章，详情见上述参考资料；撰写本文的重点是系统体系化地总结认识架构师的工做，以便于更好的互动学习和成长，部分观点是我的观点。

本文做者： 九摩

原文：《如何带领团队“攻城略地”？优秀的架构师这样作》