- 4. 整体架构
- 4.1 DevOps实践是否需要架构调整
- 4.2 架构结构总览
- 4.2.1 协作模式
- 4.2.2 资源管理
- 4.2.3 架构元素之间的映射
- 4.3 微服务架构的质量
- 4.3.1 可靠性
- 4.3.2 可修改性
从DevOps实践的五个分类来看：将运维的需求（可能是在日志、监控和支撑事故处理等领域上）纳入系统、确保开发更多的负责相关事故处理、要求所有人员执行部署过程这三种会对原有架构进行小修改；若使用持续部署，将带来最深远的架构修改；像开发应用程序代码一样开发基础设施代码，这实践不会影响应用程序代码，可能会影响基础设施代码架构。
4.2 架构结构总览模块：一个具有一致功能的代码单元；
组件：一个可执行单元；
编译器/解释器 将 模块 转化为 二进制文件，构建器 将 二进制文件 转化为 组件。
服务：用以定义 提供服务的组件；
客户端：用以定义 请求服务的组件；
为大幅度减少组件进入生产的时间，需要架构支持：
- 可以部署不需要与其他团队的显式协作；
- 让不同版本的同一个服务同时运行在生产中，可以让不同团队成员无需与该团队的其他成员协作就可以部署；
- 错误发生时执行的回滚能支持多种形式的现场测试；
微服务架构是满足以上需求的架构风格。
三种架构设计决策，（每个决策都是基础设施设计的一部分，可进行全局设计），这些决策可以去除团队间协作的需求：协作模式、资源管理和架构元素映射。
4.2.1 协作模式如果两个服务交互，则 负责这些服务的两个开发团队必须通过某种形式进行协作。包含两个方面：客户端如何发现自己需要的服务；服务间如何通信。
一般情况下，一个服务有多个服务实例，既是为了支持一个实例无法承载的大工作负荷，也是为了预防失败。
注册表可以轮询多个实例以实现负载均衡；
服务周期性重新注册或者主动检查服务的健康状态可以防止失败的实例继续提供服务，若在指定周期内未更新，则未更新服务被从注册表中移除。
**客户端和服务器之间的通信协议可以使任何远程通信协议。**如 HTTP, RPC, SOAP等。
4.2.2 资源管理4.2.2.1 创建和销毁虚拟机
为应对客户需求或者故障，可创建新虚拟机；当需求消失，则销毁对应实例。若实例是无状态（即 它们在请求之间不保留任何信息），则新的实例创建，就可以将它投入服务中。
控制组件有三种可能存在的方式：
- 服务本身负责创建或销毁实例。服务了解自己的队列长度和响应请求的性能，它将这些指标和阈值对比，超过阈值则创建或销毁虚拟机；
- 客户端或客户端链中的一个组件负责创建或销毁服务的实例。例如，基于需求，客户端知道其可能将要向服务提交一个超过预先设定阈值的请求，客户端可以主动创建服务的新实例；
- 一个外部组价监控服务实例的性能；
4.2.2.2 管理需求
一个服务的实例数 反映了 来自客户端请求的数量。
管理需求的两种方法：
- 监控性能。类似“控制组件的存在方式”
- 使用服务级别协议控制实例数量。服务的每个实例通过其服务级别协议保证其能在指定延迟下处理一定数量的请求，接着该服务的客户端知道在指定延迟下，能发送多少个请求且获得多少响应。
两种不同类型：工作指派，分配。
工作指派：将单个团队的工作打包成模块并开发模块之间的接口；
分配：每个组件（即微服务）以 独立的可部署单元存在。这允许将每个组件分配给一个（虚拟）机器或容器，或者允许将多个组件分配给一个机器。
