软件架构演化

从devops角度来看软件架构
决策派:软件架构是决策组成的
组成派:组件 + 连接件 + 约束

1. 单体架构

单体应用的全部功能被集成在一起作为一个单一的单元
单体架构更多作为应用的部署架构，未必运行在一个进程中。

2. 分层架构

2.1. "关注点分离"思想角度

一个软件被分为四层软件的系统(表现层+业务层+持久层+数据层，邻层访问)
优点:简化结构，有利于组织开发，便于独立测试、维护
缺点:不利于持续发布和部署、性能代价、扩展性差

2.2. 面向服务架构(SOA)

将绑定时间尽可能延迟，运行时绑定
使用分布式组件的集合，这些组件为其他组件提供服务，或者消费其他组件所提供的服务，而不需要知道其他组件的实现细节。
企业服务总线(ESB)：为服务之前的相互调用提供支持环境，路由服务间的消息，并对消息和数据进行必要的转换。
服务编排引擎(Orchestration Engine):根据预先定义的脚本对服务消费者与服务提供者之间进行指挥

特点:
1. 服务自身高内聚，服务间松耦合，最小化开发维护中的相互影响
2. 良好操作性
3. 模组化，高重用性
4. 服务动态识别、祖册、调用
5. 系统复杂性提高
6. 难以测试验证
7. 独立服务演化不可控:BSS的影响
原则:

2.3. 微服务架构的特点

2.4. 微服务架构的挑战

3. 云原生应用程序(Cloud nativa SaaS)

4. 微服务架构

4.1. 什么是微服务架构(MicroServices)

2012年提出微服务架构
将单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程，服务间通信采用轻量级通信机制，围绕格子业务能力构建可以通过自动部署的机制独立部署。
小而自治的系统，分布式的异步，之后通过编排的方式将一系列小型服务编排起来

4.2. 微服务架构的特点

通过服务组件化:
1. 组件是一个可独立替换或升级的软件单元，微服务架构实现组件化的方式分解成服务。
2. 服务是一种进程外的组件，通过Web服务请求或远程调用(RPC)机制通信。
3. 使用服务作为组件的主要原因是服务是可独立部署的。(符合云计算)
4. 更加明确的体现服务之间的定义。
围绕业务能力组织
1. 技术层面考虑分工情况(跨团队沟通)->围绕业务能力进行宽栈沟通。
2. 是一种产品的模式进行(而不是项目模式)，更加关注用户，如何提高用户的使用情况
内聚和解耦
1. 基于微服务构建的系统目标是尽可能的解耦和尽可能的内聚，他们拥有各自的领域逻辑。
2. 系统被划分为分离的服务时，可利用领域驱动设计的理念，将一个复杂域划分成多个限界上下文，并且映射出它们之间的关系。
3. 服务和上下文边界的确定有助于澄清和强化分离
去中心化
1. 去中心化治理(使用不同开发框架、语言、数据库)，只要有约定接口和部署规范
2. 数据去中心化:
  1. 数据存储的去中心化(一个企业共享一个数据库->每一个微服务使用自己的数据库)
  2. 数据管理的去中心化(事务:保证一致性->无事务:付出维持一致性的业务损失与修复错误的代价)
基础设施自动化:
1. 随着基础设施的自动化，特别是云和Web Services为微服务架构提供了实现可能
服务设计
1. 高可用性:(避免出现调用失败的问题):我们为每一个微服务设置完整的监控和日志，帮助我们快速发现不良突发行为。
2. 服务变更和演化:组件已经在服务中，粒度下降，可以频繁独立发布。
3. 频繁变更的部分应当抽象出来:如果会出现多次修改服务，我们应当将它抽象出来到一个单独的服务中去。

4.3. 微服务架构的核心模式

服务的注册和发现:
1. 服务消费者获取服务提供者的机制，以实现两者间的解释。

API网关(轻量级通信框架) API Gateway
1. 提供了全部客户端的单一入口点，针对不同客户端提供不同的API
2. 客户端不关心应用程序的微服务拆分方式
3. 保证客户端不受服务实例为止的影响
4. 为每个用户提供最优API(距离最近)
5. 降低请求往返次数
6. 简化调用的复杂度