整理常见架构框架与架构演进

整理常见架构框架与架构演进
1.常见架构框架： a)TOGAF框架 b)Zachman 框架 c) ITSA框架 d)DODAF 框架
2.常见架构： a) 分布式架构演进 b) 单元式架构 c) SOA架构 d )微服务架构 e)Sererless架构
3.架构管理
2. 常见架构框架
a) TOGAF
TOGAF 是 The Open Group Architecture Framework 的缩写，它由 The Open Group 开发，The Open Group 是一个非盈利的技术行业联盟，它不断更新和重申 TOGAF。

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

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

★架构内容框架
★ 参考模型
★ ADM指引和技术1、架构迭代阶段：
2、在不同水平运用ADM：
3、利益相关者分类：
★ 企业连续统一体
架构指导及支持解决方案：基础➝通用系统➝行业➝组织特定
★ 能力框架
（更多内容可以参考《TOGAF标准9.1版本》或者 /togaf
b) Zachman框架
第一个最有影响力的框架方法论就是 Zachman 框架，它是 John
Zachman 首次在1987年提出的。

Zachman 框架模型分两个维度：横向维度采用6W（what、how、where、who、when、why）进行组织，纵向维度反映了IT 架构层次，从上到下（Top-Down），分别为范围模型、企业模型、系统模型、技术模型、详细模型、功能模型。

横向结合6W，Zachman 框架分别由数据、功能、网络、人员、时间、动机分别对应回答What、How、Where、Who、When 与 Why 这六个问题。

c) ITSA框架
ITSA诞生于1986年的惠普，世界最早的企业架构框架(IT战略与架构)。

建模原则就是“Ever ything you need, and nothing you don’t”，只放你要的东西。

d) 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 还有专门的架构认证。

5 常见架构
a) 分布式架构演进
★ 初始阶段架构
特征：应用程序，数据库，文件等所有资源都放在一台服务器上。

★应用服务和数据服务以及文件服务分离
说明：好景不长，发现随着系统访问量的再度增加，webserver 机器的压力在高峰期会上升到比较高，这个时候开始考虑增加一台webserver。

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

★使用缓存改善性能
说明：系统访问特点遵循二八定律，即80%的业务访问集中在20%的数据上。

缓存分为本地缓存远程分布式缓存，本地缓存访问速度更快但缓存数据量有限，同时存在与应用程序争用内存的情况。

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

★使用“应用服务器”集群
说明：在做完分库分表这些工作后，数据库上的压力已经降到比较低了，又开始过着每天看着访问量暴增的幸福生活了。

突然有一天，发现系统的访问又开始有变慢的趋势了，这个时候首先查看数据库，压力一切正常，之后查看webserver，发现apache 阻塞了很多的请求，而应用服务器对每个请求也是比较快的，看来是请求数太高导致需要排队等待，响应速度变慢。

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

描述：使用集群是系统解决高并发、海量数据问题的常用手段。

通过向集群中追加资源，提升系统的并发处理能力，使得服务器的负载压力不再成为整个系统的瓶颈。

★数据库读写分离
说明：享受了一段时间的系统访问量高速增长的幸福后，发现系统又开始变慢了，这次又是什么状况呢，经过查找，发现数据库写入、更新的这些操作的部分数据库连接的资源竞争非常激烈，导致了系统变慢。

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

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

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

描述：为了应付复杂的网络环境和不同地区用户的访问，通过CDN 和反向代理加快用户访问的速度，同时减轻后端服务器的负载压力。

CDN 与反向代理的基本原理都是缓存。

★“分布式文件”系统和“分布式数据库”
说明：随着系统的不断运行，数据量开始大幅度增长，这个时候发现分库后查询仍然会有些慢，于是按照分库的思想开始做分表的工作
特征：数据库采用分布式数据库，文件系统采用分布式文件系统。

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

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

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

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

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

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

描述：为了应对日益复杂的业务场景，通常使用分而治之的手段将整个系统业务分成不同的产品线，应用之间通过超链接建立关系，也可以通过消息队列进行数据分发，当然更多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。

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

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

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

描述：随着业务越拆越小，应用系统整体复杂程度呈指数级上升，由于所有应用要和所有数据库系统连接，最终导致数据库连接资源不足，拒绝服务。

★分布式服务的问题和挑战：
(1) 当服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。

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

(3) 服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？
(4) 服务多了，沟通成本也开始上升，调某个服务失败该找谁？服务的参数都有什么约定？
(5) 一个服务有多个业务消费者，如何确保服务质量？
(6) 随着服务的不停升级，总有些意想不到的事发生，比如 cache 写错了导致内存溢出，故障不可避免，每次核心服务一挂，影响一大片，人心慌慌，如何控制故障的影响面？服务是否可以功能降级？或者资源劣化？
针对这些问题，下述的单元化架构，微服务架构以及Serveless 架构可以一定程度解决，另外针对业务系统，需要做到业务与业务隔离、管理域和运行域分开、业务与平台隔离方可解决上述问题。

b) 单元化架构
1、什么是单元化：单元化架构是从并行计算领域发展而来。

在分布式服务设计领域，一个单元（Cell）就是满足某个分区所有业务操作的自包含的安装。

而一个分区（Shard），则是整体数据集的一个子集，如果你用尾号来划分用户，那同样尾号的那部分用户就可以认为是一个分区。

单元化就是将一个服务设计改造让其符合单元特征的过程。

2、单元化的必要性：随着硬件的不断升级，计算机硬件能力已经越来越强，CPU越来越快，内存越来越大，网络越来越宽。

这让我们看到了在单台机器上垂直扩展的机会。

尤其是当你遇到一个性能要求和容量增长可以预期的业务，单元化给我们提供另外的机会，让我们可以有效降低资源的使用，提供更高性能的服务。

更高性能更低成本是我们的主要目标，经过单元化改造，我们得以用更少（约二分之一）的机器，获得了比原来更高（接近百倍）的性能。

性能的提升很大部分原因在于服务的本地化，而服务的集成部
署又进一步降低了资源的使用。

除了性能收益，还有很多收益，比如更好的隔离性，包括请求隔离和资源隔离，比如更友好的升级，产品可以灰度发布等。

单元化改造后对高峰的应对以及扩容方式等问题的解决。

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

再看下图单元化架构，其为性能和隔离性而设计，上层节点访问指定下层节点。

在单元化架构下，服务虽然分层划分，但每个单元自成一体。

按照层次来讲的话，所有层使用相同的分区算法，每一层都有相同数量的节点，上层节点也会访问指定的下层节点。

c) 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），并且可以在不影响其他服务的情况下更改某项服务。

d) 微服务架构
先来看看传统的web 开发方式，通过对比比较容易理解什么是Microservice Architecture。

和 Microservice 相对应的，这种方式一般被称为 Monolithic（单体式开发）。

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

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

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

★ 常见的系统架构遵循的三个标准和业务驱动力：•提高敏捷性：及时响应业务需求，促进企业发展；•提升用户体验：提升用户体验，减少用户流失；•降低成本：降低增加产品、客户或业务方案的成本。

★ 基于微服务架构的设计：
目的：有效的拆分应用，实现敏捷开发和部署。

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

★ SOA和微服务的区别：
•SOA喜欢重用，微服务喜欢重写；
•SOA喜欢水平服务，微服务喜欢垂直服务；
•SOA喜欢自上而下，微服务喜欢自下而上。

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

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

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

函数即服务（Function as a Service）：是一项基于事件驱动的函数托管计算服务。

通过函数服务，开发者只需要编写业务函数代码并设置运行的条件，无需配置和管理服务器等基础设施，函数代码运行在无状态的容器中，由事件触发且短暂易失，并完全由第三方管理，基础设施对应用开发者完全透明。

函数以弹性、高可靠的方式运行，并且按实际执行资源计费，不执行不产生费用。

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

三个less感觉很好：
•Codeless 对应的是服务开发，实现了源代码托管，你只需要关注你的代码实现，而不需要关心你的代码在哪，因为在整个开发过程中你都不会感受到代码库和代码分支的存在。

•Applicationless 对应的是服务发布，在服务化框架下，你的服务发布不再需要申请应用，也不需要关注你的应用在哪。

•Serverless 对应的则是服务运维，有了Serverless 化能力，你不再需要关注你的机器资源，Servlerless 会帮你搞定机器资源的弹性扩缩容。

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

6 架构管理
架构共赢模型
架构结果管理
参考资料：
https:///article/8538
https:///wintersun/p/8972949.html /articles/95466
/articles/104688
/tmf/documents/how-to-desigin-domain
声明：本文部分内容参考阿里内部和外部一些文章，详情见上述参考资料；撰写本文的重点是系统体系化地总结认识架构师的工作，以便于更好的互动学习和成长，部分观点是个人观点。