《微服务架构设计模式》读书笔记【TBC】

背景

四季度选了《微服务架构设计模式》,但是状态不怎么样,一个月过去了,才看了个开头。博客也好久没更新了,正好有小伙伴想换工作要学习,又激励了我一下,一起学习!选这本是因为公司也正在使用微服务的架构,Spring Cloud,Eureka。平时都在用,但是原理不太懂,出现点不常见的异常(百度不到的那种),就很懵*了,不知道要怎么解决,全靠猜(竟然也解决了,离谱.....)


第1章 逃离单体地狱

单体架构的优点

  • 开发简单
  • 易于对应用程序进行大规模的修改
  • 测试相对简单直观
  • 部署简单明了
  • 横向扩展不费吹灰之力

单体地狱

即单体架构的局限性在业务快速发展后不断显现,并且越来越难以维护

  • 过度复杂

  • 开发速度缓慢(协同工作问题)

  • 代码提交到部署周期很长,且容易出现问题

  • 难以扩展

  • 交付可靠性是一个挑战

  • 需要长期依赖某个可能已经过时的技术栈

微服务架构

  • 架构的重要性在于影响了应用的“非功能性需求”,比如 影响交付速度 的可维护性、可扩展性、可测试性
  • 扩展立方体和服务

《微服务架构设计模式》读书笔记【TBC】_第1张图片

  • 微服务的定义:把应用程序功能性分解为一组服务的架构风格。每一个服务都是由一组专注的、内聚的功能职责组成。
  • 微服务架构作为模块化的一种形式:一般的大型应用会拆分为模块,而微服务架构即使用服务作为模块化的单元,服务可以进行独立部署和扩展。
  • 每个服务都拥有自己的数据库
  • 微服务与SOA的异同【没太看懂】
  • 微服务架构的好处
    • 使大型复杂应用可以持续交付和部署
    • 每个服务都相对较小并且容易维护
    • 服务可以独立部署和扩展
    • 微服务架构可以实现团队的自治
    • 更容易实验和采纳新技术
    • 更好的容错性
  • 微服务架构的弊端
    • 服务的拆分和定义是一项挑战
    • 分布式系统带来的各种复杂性,使开发、测试、部署变得更困难
    • 当部署跨越多个服务的功能时,需要谨慎地协调更多开发团队
    • 开发者需要思考在什么阶段使用微服务架构

微服务架构的模式语言

  • 架构设计的核心是决策

微服务架构并不是“银弹”

  • 光环曲线使用5个阶段描述新兴技术的发展:过热期(期望释放的顶峰,代表了对新技术的迷恋和崇拜)-> 谷底期(失望的谷,尝试之后对新技术的失望)-> 成熟期(生产高地,理解了新技术的优缺点后开始理性地使用)【果然科学的尽头是哲学】

模式和模式语言

  • 没太理解,但是不影响往后看

微服务架构的模式语言概述

主要的模式

  • 服务拆分的相关模式
  • 通信相关的模式:通信风格、服务发现、可靠性、事务性消息、外部API
  • 实现事务管理的数据一致性相关模式
  • 在微服务架构中查询数据的相关模式
  • 服务部署的相关模式
  • 可观测性的相关模式
    • 健康检查API
    • 日志聚合
    • 分布式追踪
    • 异常追踪
    • 应用指标
    • 审计日志
  • 实现服务自动化测试的相关模式
  • 解决基础设施和边界问题的相关模式
  • 安全相关的模式

微服务之上:流程和组织

第2章 服务的拆分策略

微服务架构到底是什么

为什么架构如此重要

架构的风格

  • 分层架构
  • 六边形架构

为应用程序定义微服务架构

识别系统操作

创建抽象领域模型

定义系统操作:命令型、查询型

根据业务能力进行服务拆分

业务能力定义了一个组织的工作

识别业务能力

从业务能力到服务

根据子域进行服务拆分

拆分的指导原则

SRP:单一职责原则

设计小的、内聚的、仅含有单一职责的服务

CCP:闭包原则

把根据同样原因进行变化的服务放在一个组件内,这样可以控制服务的数量,并且更有利于变更和部署。理想情况下,一次变更,只会影响一个团队、一个服务。CPP是解决分布式单体的法宝

拆分单体应用为服务的难点

网络延迟

同步进程间通信导致可用性降低

在服务之间维持数据一致性

获取一致的数据视图

上帝类阻碍了拆分

定义服务API

把系统操作分配给服务

确定支持服务协作所需要的API

本章小结

《微服务架构设计模式》读书笔记【TBC】_第2张图片

第3章 微服务架构中的进程间通信

微服务架构中的进程间通信概述

交互方式

《微服务架构设计模式》读书笔记【TBC】_第3张图片

在微服务架构中定义API

API的演化

消息的格式

基于文本的消息格式

二进制消息格式

基于同步远程过程调用模式的通信(RPI)

使用REST

使用gRPC

使用断路器模式处理局部故障

开发可靠的远程过程调用代理

  • 网络超时
  • 限制客户端向服务器发出请求的数量
  • 断路器模式:监控请求的失败和成功比例,超过一定阀值启动断路器,让后续的调用立即失效

从服务失效故障中恢复

使用服务发现

因为服务的网络位置(IP和端口)是动态变化的,所以我们需要使用服务发现

什么是服务发现

  • 应用层服务发现模式

  • 平台层服务发现模式

《微服务架构设计模式》读书笔记【TBC】_第4张图片

基于异步消息模式的通信

什么是消息传递

  • 关于消息

《微服务架构设计模式》读书笔记【TBC】_第5张图片

  • 关于消息通道

 

 

 

 

第4章 使用Saga管理事务

第5章 微服务架构中的业务逻辑设计

第6章 使用事件溯源开发业务逻辑

第7章 在微服务架构中实现查询

第8章 外部API模式

第9章 微服务架构中的测试策略(上)

第10章 微服务架构中的测试策略(下)

第11章 开发面向生产环境的微服务应用

第12章 部署微服务应用

第13章 微服务架构的重构策略

你可能感兴趣的:(读书笔记)