系统架构师（九）软件架构设计（一）
软件架构的研究内容主要涉及软件架构描述、软件架构设计、软件架构风格、软件架构评价和软件架构的形成方法等。
软件设计人员学习软件架构知识旨在站在较高的层面上整体地解决好软件的设计、复用、质量和维护等方面的实际问题。
软件架构概念
定义 ：软件或计算机系统的软件架构是该系统的一个（或多个）结构，而结构由软件元素、元素的外部可见属性及它们之间的关系组成。
软件系统架构是关于软件系统的结构、行为和属性的高级抽象。
- 在描述阶段，主要描述直接构成系统的抽象组件以及各个组件之间的连接规则，特别是相对细致地描述组件的交互关系。
- 在实现阶段，这些抽象组件被细化为实际的组件，比如具体类或者对象。
软件系统架构不仅指定了软件系统的组织和拓扑结构，而且显示了系统需求和组件之间的对应关系，包括设计决策的基本方法和基本原理。
重要性：
- 项目关系人之间交流的平台。
- 早期设计决策。
- 在较高层面上实现软件复用
- 架构对开发的指导与规范意义不容忽略
软件架构的建立应位于概要设计之前，需求分析之后
架构的模型： 将 5 种模型有机地统一在一起刻画软件架构
- 结构模型：以架构的构件、连接件和其他概念来刻画结构
- 框架模型：以一些特殊的问题为目标建立只针对和适应该问题的结构
- 动态模型：研究系统“大颗粒”的行为性质
- 过程模型：研究构造系统的步骤和过程
- 功能模型：架构由一组功能构件按层次组成
“4+1”的视图模型
逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构 。
（1） 逻辑视图 ： 主要支持系统的功能需求 ，即系统提供给最终用户的服务 。逻辑视图中使用的风格为面向对象的风格，逻辑视图设计中要注意的主要问题是要保持一个单一的、内聚的对象模型贯穿整个系统。
（2） 开发视图 ： 也称为模块视图 ， 主要侧重于软件模块的组织和管理。
（3） 进程视图 ： 侧重于系统的运行特性 ， 主要关注一些非功能性的需求 ， 例如系统的性能和可用性 。进程视图强调并发性、分布性、系统集成性和容错能力，以及逻辑视图中的主要抽象的进程结构。
（4） 物理视图 ： 主要考虑如何把软件映射到硬件上 ， 它通常要考虑到解决系统拓扑结构 、 系统安装 、 通信等问题 。
（5） 场景 （用例视图）： 可以看作是那些重要系统活动的抽象 ， 它使四个视图有机地联系起来 ， 从某种意义上说，场景是最重要的需求抽象。分析人员和测试人员关心的是系统的行为，因此会侧重于用例视图；
软件质量属性
软件质量特性包括功能性、可靠性、易用性、效率、可维护性、可移植性等 6个方面，每个方面都包含若干个子特性。
- 功能性： 适合性、准确性、互操作性、依从性、安全性；
- 可靠性： 成熟性、容错性、易恢复性；
- 易用性： 易理解性、易学性、易操作性；
- 效率： 时间特性、资源特性；
- 可维护性： 易分析性、易改变性、稳定性、易测试性；
- 可移植性： 适应性、易安装性、遵循性、易替换性；
运行期质量属性
- 性能：指软件系统及时提供相应服务的能力。（速度、吞吐量、持续高速性）
- 安全性：指软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力。
- 易用性：指软件系统易于被使用的程度。
- 可伸缩性：指当用户数和数据量增加时，软件系统维持高服务质量的能力。例如，通过增加 服务器来提高能力。
- 互操作性：与其他系统交换数据和相互调用服务的难易程度。
- 可靠性：在一定的时间内无故障运行的能力。
- 持续可用性：指系统长时间无故障运行的能力。与可靠性相关联，常将其纳入可靠性中。
- 鲁棒性：是指软件系统在一些非正常情况（如用户进行了非法操作、相关的软硬件系统发生 了故障等）下仍能够正常运行的能力。也称健壮性或容错性。
开发期质量属性
- 易理解性：指设计被开发人员理解的难易程度。
- 可扩展性：软件因适应需求变化而增加新功能的能力。也称为灵活性。
- 可重用性：指重用软件系统或某一部分的难易程度。
- 可测试性：对软件测试以证明其满足需求规范的难易程度。
- 可维护性：当需要修改缺陷、增加功能、提高质量属性时，定位修改点并实施修改的难易程度；
- 可移植性：将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。
一般的质量属性场景（一般场景）指独立于具体系统、适合于任何系统的一般性场景；
具体的质量属性场景（具体场景）指适合于正在考虑的某 个特定系统的场景，具体场景通常是指从一般场景中抽取特定的、面向具体系统的内容。
可用性：
可用性战术的目标是阻止错误发展成故障，至少能够把错误的影响限制在一定范围内，从而使修复成为可能。战术分为：错误检测、错误恢复、错误预防。
① 错误检测：命令/响应、心跳（计时器）、异常（异常处理程序）
② 错误恢复：
- 表决：由表决器按表决算法（如多数规则）确定是否有构件出错，通常用在控制系统中。
- 主动冗余（热重启、热备份）：冗余构件并行响应，错误发生时切换使用另一个构件的响应。
- 被动冗余（暧重启/双冗余/三冗余）：一个构件（主构件）对事件做出响应，并通知其他构件（备用的）必须进行的状态更新（同步）。当错误发生时，备用构件从最新同步点接替主构件的工作。
- 备件：备件是计算平台配置用于更换各种不同的故障构件。
- 状态再同步：所恢复的构件在重新提供服务前更新其状态。
- 检查点/回滚：检查点就是使状态一致的同步点
③ 错误预防：事务、进程监视器、从服务中删除（如删除进程再重新启动，以防止内存泄露导致故障的发生）
可修改性：
包括局部化修改、防止连锁反应、推迟绑定时间。
① 局部化修改：在设计期间为模块分配责任，以便把预期的变更限制在一定的范围内，从而降低修改的成本。
② 防止连锁反应。降低模块之间有各种依赖性
- 信息隐藏
- 维持现有的接口稳定性。
- 限制通信路径
- 仲裁者的使用
③ 推迟绑定时间：在运行时进行绑定并允许非开发人员进行修改（配置）。
性能：
性能与时间相关，影响事件的响应时间有两个基本因素：资源消耗、闭锁时间
① 资源需求：减少处理事件流所需的资源、减少所处理事件的数量、控制资源的使用
② 资源管理：引入并发、维持数据或计算的多个副本、增加可用资源
③ 资源仲裁：先进/先出（FIFO）、固定优先级调度、动态优先级调度、静态调度（离线确定调度）
安全性：
① 抵抗攻击：
- 对用户进行身份验证
- 对用户进行授权
- 维护数据的机密性：一般通过对数据和通信链路进行加密来实现；
- 维护完整性：对数据添加校验或哈希值； 限制暴露的信息；
- 限制访问：如用防火墙、DMZ 策略。
② 检测攻击：通过“入侵检测”系统进行过滤、比较通信模式与历史基线等方法。
③ 从攻击中恢复：
- 恢复：与可用性中的战术相同；
- 识别攻击者：作为审计追踪，用于预防性或惩罚性目的。
可测试性：
① 输入/输出：
- 记录/回放：指捕获跨接口的信息，并将其作为测试专用软件的输入；
- 将接口与实现分离：允许使用实现的替代（模拟器）来支持各种测试目的；
- 优化访问线路/接口：用测试工具来捕获或赋予构件的变量值。
② 内部监控。当监视器处于激活状态时，记录事件（如通过接口的信息）。
易用性：
① 运行时战术：
- 任务的模型：维护任务的信息，使系统了解用户试图做什么，并提供各种协助；
- 用户的模型：维护用户的信息，例如使系统以用户可以阅读页面的速度滚动页面；
- 系统的模型：维护系统的信息，它确定了期望的系统行为，并向用户提供反馈。
② 设计时战术：将用户接口与应用的其余部分分离开来，预计用户接口会频繁发生变化，因此，单独维护用户接口代码将实现变更局部化。这与可修改性相关。
③ 支持用户主动操作。支持用户的主动操作，如支持“取消”、“撤销”、“聚合”和 “显示多个视图”。
软件架构风格
软件架构设计的一个核心问题是能否使用重复的软件架构模式，即能否达到架构级别的软件重用。
软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义了一个系统家族，即一个架构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。
架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。
通用架构风格
（1）数据流风格：
- 批处理序列：顺序执行，数据传送在步与步之间作为一个 整体。
- 管道/过滤器：
- 具有良好的隐蔽性和高内聚、低耦合的特点；
- 允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成；
- 支持软件重用
- 系统维护和增强系统性能简单
- 允许对一些如吞吐量、死锁等属性的分析；
- 支持并行执行。
区别：批处理是全部的、高潜伏性的，输入时可随机存取，无合作性、无交互性。而管道过滤器是递增的，数据结果延迟小，输入时处理局部化，有反馈、可交互。批处理强调数据传送在步与步之间作为一个整体，而管理过滤器无此要求。
（2）调用/返回风格：（分而治之策略）
- 主程序/子程序：结构化开发风格，采用单线程控制，把问题划分为若干处理步骤
- 面向对象风格：
- 对象负责维护其表示的完整性；
- 对象的表示对其他对象而言是隐蔽的。
- 层次结构：最广泛的应用是 分层通信协议。
- 支持基于抽象程度递增的系统设计
- 支持功能增强（功能的改变最多影响相邻的上下层）
- 支持重用
（3）独立构件风格： 构件之间不直接通信
-
进程通信：构件是独立的过程，连接件是消息传递。
-
事件系统：（隐式调用）构件触发或广播事件，调用在这个事件中注册的所有过程
隐式调用系统的优点 ：
- 为软件重用提供了强大的支持
- 为改进系统带来了方便
缺点：
- 构件放弃了对系统计算的控制
- 数据交换的问题（共享仓库交互）
（4）虚拟机风格： 人为构建一个运行环境，解析与运行自定义的语言，增加灵活性
- 解释器：虚拟机、执行效率较低
- 完成解释工作的解释引擎
- 将被解释的代码的存储区
- 记录解释引擎当前工作状态的数据结构
- 记录源代码被解释执行进度的数据结构
- 基于规则的系统：包括规则集、规则解释器、规则/数据选择器及工作内存。
（5）仓库风格：
- 数据库系统：最常见
- 中央共享数据源：保存当前系统的数据状态；
- 多个独立处理元素：处理元素对数据元素进行操作。
- 超文本系统：如早期的静态网页
- 黑板系统：适合于解决复杂的非结构化的问题
- 在抽象与总结语言理解系统 HEARSAY-11 的基础上产生
- 是一种问题求解模型，是组织推理步骤、控制状态数据和问题求解之领域知识的概念框架。
- 黑板系统的传统应用是信号处理领域，如语音和模式识别，另一应用是松耦合代理数据共享存取。
黑板系统主要由三部分组成：
- 知识源。包含独立的、与应用程序相关的知识，知识源之间不直接进行通信，它们之间的交互只通过黑板来完成。
- 黑板数据结构：按照与应用程序相关的层次来组织的解决问题的数据，知识源通过不断地改变黑板数据来解决问题。
- 控制。控制完全由黑板的状态驱动，黑板状态的改变决定使用的特定知识。
除上述五种风格外，还有几个风格：
（1） 闭环控制架构（过程控制）： 适合于嵌入式系统，涉及连续的动作与状态
当软件被用来操作以一个物理系统时，软件与硬件之间可以粗略地表示 为一个反馈循环，这个反馈循环通过接受一定的输入，确定一系列的输出，最终是环境达到一个新的状态。
（2）模型驱动架构（MDA） 采用了模型和技术分离的架构设计。
使用一定的建模标准（UML、MOF、XMI等）构建描述应用程序或集成系统的业务功能和行为的模型，这些模型独立于具体平台并且和实现具体业务功能和行为的特定技术代码分离，从而实现了业务和应用程序逻辑与底层平台技术的分离
MDA三大目标：轻便可移植性、互操作性和可重用性；
MDA三种核心模型：
- 平台独立模型（PIM）：具有高抽象层次，独立于任何实现技术的模型；
- 平台相关模型（PSM）：为某种特定实现技术量身定做，让你用这种技术中可用的实现构造来描述系统的模型，PIM会被变换成一个或多个PSM
- 代码code：用源代码对系统的描述（规约）。每个PSM都将被变换成代码
（3）C2体系结构风格： 通过连接件绑定在一起的按照一组规则运作的并行构件网络。
C2风格中的系统组织规则如下：
① 系统中的构件和连接件都有一个顶部和一个底部；
② 构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件之间的直接连接是不允许的；
③ 一个连接件可以和任意数目的其他构件和连接件连接；
④ 当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。
层次系统架构风格
C/S 架构风格（二层及三层）
C/S 架构是基于资源不对等，且为实现共享而提出来的；
C/S 结构将应用一分为二，服务器（后台）负责数据管理，客户机（前台）完成与用户的交互任务。
C/S 软件架构具有强大的数据操作和事务处理能力，模型思想简单
二层 C/S 结构局限：
- 二层 C/S 结构为单一服务器且以局域网为中心，难以扩展至大型企业广域网或Internet；
- 软、硬件的组合及集成能力有限；
- 服务器的负荷太重，难以管理大量的客户机，系统的性能容易变坏；
- 数据安全性不好。客户端程序可以直接访问数据库服务器。
三层 C/S 结构： 将应用功能分成表示层、功能层和数据层三个部分
- 表示层是应用的用户接口部分，它担负着用户与应用间的对话功能。它用于检查用户从键盘等输入的数据，并显示应用输出的数据。
- 功能层相当于应用的本体，它是将具体的业务处理逻辑编入程序中。
- 数据层就是数据库管理系统，负责管理对数据库数据的读写。数据库管理系统必须能迅 速执行大量数据的更新和检索。
B/S 架构风格 （浏览器/服务器）
不足：
（1）B/S 架构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能。
（2）采用 B/S 架构的应用系统，在数据查询等响应速度上，要远远地低于 C/S 架构。
（3）B/S 架构的数据提交一般以页面为单位，数据的动态交互性不强，不利于在线事务处理（OnLine Transaction Processing，简称 OLTP）应用。
MVC 架构风格
（1）Model 是对应用状态和业务功能的封装，我们可以将它理解为同时包含数据和行为的领域模型。Model 接受 Controller 的请求并完成相应的业务处理，在状态改变的时候向 View 发出相应的通知。
（2）View 实现可视化界面的呈现并捕捉最终用户的交互操作（例如鼠标和键盘的操作）。
（3）View 捕获到用户交互操作后会直接转发给 Controller，后者完成相应的 UI 逻辑。如果需要涉及业务功能的调用，Controller 会直接调用 Model。在完成 UI 处理后，Controller会根据需要控制原 View 或者创建新的 View 对用户交互操作予以响应。
MVP 架构风格
MVP 避免了 View 和 Model 之间的耦合，降低了 Presenter 对 View的依赖。
MVP 的优点：
（1）模型与视图完全分离，我们可以修改视图而不影响模型。
（2）可以更高效地使用模型，因为所有的交互都发生在Presenter 内部。
（3）我们可以将一个 Presenter 用于多个视图，而不需要改变 Presenter 的逻辑。
（4）如果我们把逻辑放在 Presenter 中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）。
MVP 的缺点：
由于对视图的渲染放在了 Presenter 中，所以视图和 Presenter 的交互会过于频繁。一旦视图需要变更，那么 Presenter 也需要变更了。
面向服务的架构 SOA
SOA 是一种在计算环境中设计、开发、部署和管理离散逻辑单元（服务）模型的方法。
SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。
定义： 是一种粗粒度、松耦合的服务架构，服务间通过定义良好的、简单、明确的接口定义进行通信，客户端可以按特定顺序调用这些服务形成业务逻辑。
在 SOA 模型中，所有的功能都定义成了独立的服务。服务之间通过交互和协调完成业务的整体逻辑。所有的服务通过服务总线或流程管理器来连接。这种松散耦合的架构使得各服务在交互过程中无需考虑双方的内部实现细节，以及部署在什么平台上。
SOA 设计原则：
- 明确定义的接口
- 自包含和模块化
- 粗粒度
- 松耦合
- 互操作性、兼容和策略声明
SOA 的关键技术： (以 XML 为基础)
SOA 能够在最新的和现有的系统之上创建应用，借助现有的应用产生新的服务，为企业提供更好的灵活性来构建系统和业务流程。
- UDDI：（统一描述、发现和集成）提供了一种服务发布、查找和定位的方法，定义了接口和服务注册规范，使企业可根据业务自定义创建服务并注册到SOA的注册中心中、或发现特定服务并使用其功能。
- 数据模型：用于描述业务组织和服务的 XML Schema。
- API：一组用于查找或发布 UDDI 数据的方法，基于 SOAP。
- 注册服务
- WSDL：（服务描述语言）描述WEB服务和与WEB服务进行通信的XML语言。描述了服务的功能、服务交互的数据格式和协议格式、服务的地址。分为服务接口定义和服务实现定义
- SOAP：（简单对象访问协议） 用 XML 来格式化消息，用 HTTP 来承载消息；定义了服务请求者和提供者之间的消息传输规范。SOAP 消息基本上是从发送端到接收端的单向传输，但它们常常结合起来执行类似于请求/应答的模式。
- 封装。SOAP 封装定义了一个整体框架，用来表示消息。
- 编码规则。定义一种序列化的机制，用于交换系统所定义的数据类型的实例。
- RPC 表示。表示定义了一个用来表示远程过程调用和应答的协议。
- 绑定。定义了一个使用底层传输协议来完成在节点之间交换 SOAP 封装的约定。
- REST：（表述性状态转移）使用 HTTP 和 XML 的 Web 通信技术，降低开发的复杂性，提高系统的可伸缩性。具有简单性和缺少严格配置文件的特性
- 网络上的所有事物都被抽象为资源。
- 每个资源对应一个唯一的资源标识。
- 通过通用的连接件接口对资源进行操作。
- 对资源的各种操作不会改变资源标识。
- 所有的操作都是无状态的。
| 功能 | 协议 |
|---|---|
| 发现服务 | UDDI、DISCO |
| 描述服务 | WSDL、XML Schema |
| 消息格式层 | SOAP、REST |
| 编码格式层 | XML(DOM、SAX) |
| 传输协议层 | HTTP、TCP/IP、SMTP等 |
SOA 的实现方法
1. Web Service
- 服务提供者：负责定义并实现服务，使用 WSDL对服务进行详细、准确、规范地描述，并将该描述发布到服务注册中心
- 服务请求者：查找、绑定并调用服务，可以由浏览器来担当，由人或程序来控制。
- 服务注册中心：连接服务提供者和服务请求者的纽带。
图注：服务提供者和服务请求者是必需的，服务注册中心是一个可选的角色。例如，如果使用静态绑定的服务，服务提供者则可以把描述直接发送给服务请求者。
在采用 Web Service 作为 SOA 的实现技术时，应用系统大致可以分为六个层次，分别是底层传输层、服务通信协议层、服务描述层、 服务层、业务流程层和服务注册层。
- 底层传输层：主要负责消息的传输机制，HTTP、JMS（Java MessagingService，Java 消息服务）和 SMTP 都可以作为服务的消息传输协议，其中 HTTP 使用最广。
- 服务通信协议层：主要功能是描述并定义服务之间进行消息传递所需的技术标准，常用的标准是 SOAP 和 REST 协议。
- 服务描述层：主要以一种统一的方式描述服务的接口与消息交换方式，相关的标准是 WSDL。
- 服务层：主要功能是将遗留系统进行包装，并通过发布的 WSDL 接口描述被定位和调用。
- 业务流程层：主要功能是支持服务发现，服务调用和点到点的服务调用，并将业务流程从服务的底层调用抽象出来。
- 服务注册层：主要功能是使服务提供者能够通过 WSDL 发布服务定义，并支持服务请求者查找所需的服务信息。相关的标准是 UDDI。
2. 服务注册表：
提供一个策略执行点（Policy Enforcement Point，PEP），在这个点上，服务可以在 SOA 中注册，从而可以被发现和使用。
- 服务注册：指服务提供者向服务注册表发布服务的功能（服务合约），包括服务身份、位置、方法、绑定、配置、方案和策略等描述性属性。
- 服务位置：指服务使用者，帮助它们查询已注册的服务，寻找符合自身要求的服务。这种查找主要是通过检索服务合约来实现的
- 服务绑定：服务使用者利用查找到的服务合约来开发代码，开发的代码将与注册的服务进行绑定，调用注册的服务，以及与它们实现互动。
3. 企业服务总线：
ESB 是一种为进行连接服务提供的标准化的通信基础结构，基于开放的标准，为应用提供了一个可靠的、可度量的和高度安全的环境，帮助企业对业务流程进行设计和模拟，对每个业务流程实施控制和跟踪、分析并改进流程和性能。
ESB 是由中间件技术实现并支持 SOA 的一组基础架构，与 是传统中间件技术与 XML、Web Service 等技术结合的产物 ，是在整个企业集成架构下的面向服务的企业应用集成机制。
（1）支持异构环境中的服务、消息和基于事件的交互，并且具有适当的服务级别和可管理性。
（2）通过使用 ESB，可以在几乎不更改代码的情况下，以一种无缝的非侵入方式使现有系统具有全新的服务接口，并能够在部署环境中支持任何标准。
（3）充当缓冲器的 ESB（负责在诸多服务之间转换业务逻辑和数据格式）与服务逻辑相分离，从而使不同的系统可以同时使用同一个服务，不用在系统或数据发生变化时，改动服务代码。
（4）在更高的层次，ESB 还提供诸如服务代理和协议转换等功能。允许在多种形式下通过像 HTTP、SOAP 和 JMS 总线的多种传输方式，主要是以网络服务的形式，为发表、注册、发现和使用企业服务或界面提供基础设施。
（5）提供可配置的消息转换翻译机制和基于消息内容的消息路由服务，传输消息到不同的目的地。
（6）提供安全和拥有者机制，以保证消息和服务使用的认证、授权和完整性。
ESB 优势：
（1）扩展的、基于标准的连接。ESB 形成一个基于标准的信息骨架，使得在系统内部和整个价值链中可以容易地进行异步或同步数据交换。
（2）灵活的、服务导向的应用组合。基于 SOA，ESB 使复杂的分布式系统（包括跨多个应用、系统和防火墙的集成方案），使系统具有高度可扩展性。
（3）提高复用率，降低成本。
（4）减少市场反应时间，提高生产率。ESB 通过构件和服务复用，按照 SOA 的思想简化应用组合，基于标准的通信、转换和连接来实现这些优点。
微服务
微服务的核心特点为：小, 且专注于做⼀件事情、轻量级的通信机制、松耦合、独立部署。
微服务的优势：
- 技术异构性：每个服务都是一个相对独立的个体，都可以选择适合于自身的技术来实现。可以混合使用多种编程语言、开发框架以及数据存储技术
- 扩展：单块系统中，我们要做扩展，往往是整体进行扩展。而在微服务架构中，可以针对单个服务进行扩展。
- 简化部署：简单的服务更容易部署, 每个服务的部署都是独立的, 单个服务出问题不会导致整个系统的故障.
- 与组织结构相匹配：为服务强调模块化的结构, 可以将架构与组织结构相匹配，避免出现过大的代码库，从而获得理想的团队大小及生产力。
- 可组合性：系统会开放很多接口供外部使用。当情况发生改变时，可以使用不同的方式构建应用
- 对可替代性的优化：可以在需要时轻易地重写服务，或者删除不再使用的服务。
微服务面临的挑战：
- 分布式系统的复杂度：通过网络通信，性能、可靠性、数据一致性受影响
- 运维成本：每个服务都需要独立的 配置、部署 、监控、日志收集等，因此运维成本呈指数级增长。
- 部署自动化：每个服务的修改都需要独立部署。很难有效地构建自动化部署流水线，降低部署成本、提高部署频率。
- DevOps 与组织结构：微服务不仅表现出一种架构模型，同样也表现出一种组织模型。这种新型的组织模型意味着开发人员和运维的角色发生了变化，开发者将承担起服务整个生命周期的责任，包括部署和监控，而运维也越来越多地表现出一种顾问式的角色，尽早考虑服务如何部署。
- 服务间依赖测试：
- 服务间依赖管理：如何清晰有效地展示服务之间的依赖关系
客户机/服务器系统开发时可以采用不同的分布式计算架构：
- 分布式表示架构是将表示层和表示逻辑层迁移到客户机，应用逻辑层、数据处理层和数据层仍保留在服务器上；
- 分布式数据架构是将数据层和数据处理层放置于服务器，应用逻辑层、表示逻辑层和表示层放置于客户机；
- 分布式数据和应用架构是将数据层和数据处理层放置在数据服务器上，应用逻辑层放置在应用服务器上，表示逻辑层和表示层放置在客户机上。
分布式系统开发分为5个逻辑计算层：
- 表示层实现用户界面；
- 表示逻辑层包括为了生成数据表示而必须进行的处理任务，如输入数据编辑等；
- 应用逻辑层包括为支持实际业务应用和规则所需的应用逻辑和处理过程，如信用检查、数据计算和分析等；
- 数据处理层包括存储和访问数据库中的数据所需的应用逻辑和命令，如查询语句和存储过程等：
- 数据层是数据库中实际存储的业务数据。
微服务与SOA对比：
