- 从devops角度来看软件架构决策派:软件架构是决策组成的组成派:组件 + 连接件 + 约束
- 单体应用的全部功能被集成在一起作为一个单一的单元单体架构更多作为应用的部署架构，未必运行在一个进程中。
- 一个软件被分为四层软件的系统(表现层+业务层+持久层+数据层，邻层访问)优点:简化结构，有利于组织开发，便于独立测试、维护缺点:不利于持续发布和部署、性能代价、扩展性差
- 将绑定时间尽可能延迟，运行时绑定使用分布式组件的集合，这些组件为其他组件提供服务，或者消费其他组件所提供的服务，而不需要知道其他组件的实现细节。企业服务总线(ESB)：为服务之前的相互调用提供支持环境，路由服务间的消息，并对消息和数据进行必要的转换。服务编排引擎(Orchestration Engine):根据预先定义的脚本对服务消费者与服务提供者之间进行指挥
- 特点:
- 服务自身高内聚，服务间松耦合，最小化开发维护中的相互影响良好操作性模组化，高重用性服务动态识别、祖册、调用系统复杂性提高难以测试验证独立服务演化不可控:BSS的影响
- 2012年提出微服务架构将单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程，服务间通信采用轻量级通信机制，围绕格子业务能力构建可以通过自动部署的机制独立部署。小而自治的系统，分布式的异步，之后通过编排的方式将一系列小型服务编排起来
- 通过服务组件化:
- 组件是一个可独立替换或升级的软件单元，微服务架构实现组件化的方式分解成服务。服务是一种进程外的组件，通过Web服务请求或远程调用(RPC)机制通信。使用服务作为组件的主要原因是服务是可独立部署的。(符合云计算)更加明确的体现服务之间的定义。
- 技术层面考虑分工情况(跨团队沟通)->围绕业务能力进行宽栈沟通。是一种产品的模式进行(而不是项目模式)，更加关注用户，如何提高用户的使用情况
- 基于微服务构建的系统目标是尽可能的解耦和尽可能的内聚，他们拥有各自的领域逻辑。系统被划分为分离的服务时，可利用领域驱动设计的理念，将一个复杂域划分成多个限界上下文，并且映射出它们之间的关系。服务和上下文边界的确定有助于澄清和强化分离
- 去中心化治理(使用不同开发框架、语言、数据库)，只要有约定接口和部署规范数据去中心化:
- 数据存储的去中心化(一个企业共享一个数据库->每一个微服务使用自己的数据库)数据管理的去中心化(事务:保证一致性->无事务:付出维持一致性的业务损失与修复错误的代价)
- 随着基础设施的自动化，特别是云和Web Services为微服务架构提供了实现可能
- 高可用性:(避免出现调用失败的问题):我们为每一个微服务设置完整的监控和日志，帮助我们快速发现不良突发行为。服务变更和演化:组件已经在服务中，粒度下降，可以频繁独立发布。频繁变更的部分应当抽象出来:如果会出现多次修改服务，我们应当将它抽象出来到一个单独的服务中去。
- 服务的注册和发现:
- 服务消费者获取服务提供者的机制，以实现两者间的解释。
- API网关(轻量级通信框架) API Gateway
- 提供了全部客户端的单一入口点，针对不同客户端提供不同的API客户端不关心应用程序的微服务拆分方式保证客户端不受服务实例为止的影响为每个用户提供最优API(距离最近)降低请求往返次数简化调用的复杂度
- 熔断器模式:
- 微服务之间难免存在依赖关系，同时相互之间通过网络进行通信，一旦任何服务或网络出现问题导致请求错误，可能会导致级联故障，将不可用在系统中逐渐放大
- JenKins:支持将近1000个服务
- 开发服务封装服务部署服务注册服务调用服务
