小磊哥er的大前端学习笔记

Appearance

《微服务设计》精读笔记 ​

写在前面 ​

  • 书籍介绍：本书主要内容包括认识微服务在保证系统设计与组织目标统一上的重要性，学会把服务集成到已有系统中，采用递增手段拆分单块大型应用，通过持续集成部署微服务，等等。
  • 我的简评：暂无
  • ！！福利：文末有pdf书籍、笔记思维导图、随书代码打包下载地址哦

1.微服务介绍 ​

  • 1.什么：1. 很小，专注于做好一件事情；2. 自治性
  • 2.好处：1. 技术异构性；2. 弹性；3. 扩展；4. 简化部署；5. 与组织结构相匹配；6. 可组合性；7. 对可替代性的优化
  • 3.面向服务的架构：1. SOA，可以认为微服务架构是SOA的一种特定方法
  • 4.其他的分解技术：1. 共享库；2. 模块

2.演化式架构师 ​

    1. 不准确的比较：1. 跟建筑师作比较
    1. 架构师的演化视角：1. 架构师应该像城市规划师那样专注在大方向上，只在很有限的情况下参与到非常具体的细节实现上
    1. 分区：1. 区域的概念对应的应该是我们的服务边界，或者是一些粗粒度的服务群组；2. 作为架构师，不应该过多关注每个区域内发生的事情，而应该多关注区域之间的事情
    1. 一个原则性的方法：1. 做系统设计方面的决定通常都是在做取舍；2. 战略目标；3. 原则；4. 实践；5. 将原则和实践结合
    1. 要求的标准：1. 监控；2. 接口；3. 架构安全性
    1. 代码治理
    1. 技术债务：1. 架构师的职责就是从更高的层次出发，理解如何做权衡
    1. 例外管理
    1. 集中治理和领导：1. 架构师会对很多事情负责；2. 他们需要确保有一组可以指导开发的原则，并且这些原则要与组织的战略相符
    1. 建设团队：1. 帮助你的队友成长，帮助他们理解愿景；2. 保证他们可以积极地参与到愿景的实现和调整中来
    1. 小结：一个演进式架构师应该承担的责任：1. 愿景：确保在系统级有一个经过充分沟通的技术愿景；2. 同理心：理解你所做的决定对客户和同事带来的影响；3. 合作：和尽量多的同事进行沟通；4. 适应性：确保在你的客户和组织需要的时候调整这个愿景；5. 自治性：在标准化和团队自治之间寻找一个正确的平衡点；6. 治理：确保系统按照技术愿景的要求实现

3.建模服务 ​

    1. MusicCorp例子
    1. 什么是好服务：1. 松耦合：应该尽可能少的知道与之协作的那些服务的信息；2. 高内聚：把相关的行为聚集在一起，把不相关的行为放在别处
    1. 限界上下文：1. 一个喜欢的定义：一个由显式边界限定的特定职责；2. 共享的隐藏模型；3. 模块和服务；4. 过早划分
    1. 业务功能：1. 当在思考组织内的限界上下文时，不应该从共享数据的角度来考虑，而应该从这些上下文能够提供的功能来考虑
    1. 逐步划分上下文
    1. 业务概念的沟通
    1. 技术边界

4.集成 ​

    1. 寻找理想的集成技术：1. 避免破坏性修改；2. 保证API的技术无关性；3. 使你的服务易于消费方使用；4. 隐藏内部实现细节
    1. 为用户创建接口
    1. 共享数据库：1. 服务之间很容易通过数据库集成来共享数据，但是无法共享行为
    1. 同步与异步：1. 两种不同的通信模式有着各自的协作风格：请求/响应式或者基于事件
    1. 编排与协同：1. 编排方式的缺点：客户服务作为中心控制点承担了太多职责，他会成为网状结构的中心枢纽及很多逻辑的起点；2. 使用协同的方式可以降低系统的耦合度，并且能更加灵活的对现有系统进行修改
    1. 远程过程调用：1. 技术的耦合；2. 本地调用和远程调用并不相同（RPC的核心想法是隐藏远程调用的复杂性）；3. 脆弱性；4. RPC很糟糕吗
    1. REST：1. REST是RPC的一种替代方案；2. REST和HTTP（1. HTTP周边也有一个大的生态系统，其中包含很多支撑工具和技术）；3. 超媒体作为程序状态的引擎；4. JSON、XML还是其他；5. 留心过多的约定；6. 基于HTTP的REST的缺点
    1. 基于事件的异步协作方式：1. 技术选型；2. 异步架构的复杂性
    1. 服务即状态机
    1. 响应式扩展
    1. DRY和代码重用的危险
    1. 按引用访问
    1. 版本管理：1. 尽可能推迟；2. 及早发现破坏性修改；3. 使用语义化的版本管理；4. 不同的接口共存；5. 同时使用多个版本的服务
    1. 用户界面：1. 走向数字化；2. 约束；3. API组合；4. UI片段的组合；5. 为前端服务的后端；6. 一种混合方式
    1. 与第三方集成：1. 缺乏控制；2. 定制化；3. 意大利面式的集成；4. 在自己可控的平台进行定制化；5. 绞杀者模式

5.分解 ​

  • 5.1. 关键是接缝
  • 5.2. 分解MusicCorp
  • 5.3. 分解单块系统的原因：1. 改变的速度；2. 团队结构；3. 安全；4. 技术
    1. 杂乱的依赖
    1. 数据库
    1. 找到问题的关键
    1. 例子：打破外键关系
    1. 例子：共享静态数据
    1. 例子：共享数据
    1. 例子：共享表
    1. 重构数据库：1. 实施分离
    1. 事务边界：1. 再试一次；2. 终止整个操作；3. 分布式事务
    1. 报表
    1. 报表数据库
    1. 通过服务调用来获取数据
    1. 数据导出
    1. 事件数据的导出
    1. 数据导出的备份
    1. 走向实时
    1. 修改的代价
    1. 理解根本原因

6.部署 ​

    1. 持续集成介绍
    1. 把持续集成映射到微服务
    1. 构建流水线和持续交付
    1. 平台特定的构建物
    1. 操作系统构建物
    1. 定制化镜像：1. 将镜像作为构建物；2. 不可变服务器
    1. 环境
    1. 服务配置
    1. 服务与主机之间的映射：1. 单主机多服务；2. 应用程序容器；3. 每个主机一个服务；4. 平台即服务
    1. 自动化
    1. 从物理机到虚拟机：1. 传统的虚拟化技术；2. Vagrant；3. Linux容器；4. Docker
    1. 一个部署接口

7.测试 ​

    1. 测试类型
    1. 测试范围：1. 单元测试；2. 服务测试；3. 端到端测试；4. 权衡；5. 比例
    1. 实现服务测试：1. mock还是打桩；2. 智能的打桩服务
    1. 微妙的端到端测试
    1. 端到端测试的缺点
    1. 脆弱的测试：1. 谁来写这些测试；2. 测试多长时间；3. 大量的堆积；4. 元版本
    1. 测试场景，而不是故事
    1. 拯救我们的消费者驱动的测试：1. Pact；2. 关于沟通
    1. 还应该使用端到端测试吗
    1. 部署后再测试：1. 区分部署和上线；2. 金丝雀发布；3. 平均修复时间胜过平均故障间隔时间
    1. 跨功能测试

8.监控 ​

    1. 单一服务，单一服务器
    1. 单一服务，多个服务器
    1. 多个服务，多个服务器
    1. 日志，日志，更多的日志
    1. 多个服务的指标跟踪
    1. 服务指标
    1. 综合监控：1. 实现语义监控
    1. 关联标识
    1. 级联
    1. 标准化
    1. 考虑受众
    1. 未来

9.安全 ​

    1. 身份验证和授权：1. 常见的单点登录实现；2. 单点登录网关；3. 细粒度的授权
    1. 服务间的身份验证和授权：1. 在边界内允许一切；2. HTTP(S)基本身份验证；3. 使用SAML或OpenID Connect；4. 客户端证书；5. HTTP之上的HMAC；6. API密钥；7. 代理问题
    1. 静态数据的安全：1. 使用众所周知的加密算法；2. 一起皆与密钥相关；3. 选择你的目标；4. 按需解密；5. 加密备份
    1. 深度防御：1. 防火墙；2. 日志；3. 入侵检测（和预防）系统；4. 网络隔离；5. 操作系统
    1. 保持节俭
    1. 人的因素
    1. 黄金法则
    1. 内建安全
    1. 外部验证

10.系统设计 ​

    1. 证据：1. 松耦合组织和紧耦合组织；2. Windows Vista
    1. Netflix和Amazon
    1. 我们可以做什么
    1. 适应沟通途径
    1. 服务所有权
    1. 共享服务的原因：1. 难以分割；2. 特性团队；3. 交付瓶颈
    1. 内部开源：1. 守护者的角色；2. 成熟；3. 工具
    1. 限界上下文和团队结构
    1. 孤儿服务
    1. 反向的康威定律
    1. 人

11.规模化 ​

    1. 故障无处不在
    1. 多少是太多
    1. 功能降级
    1. 架构性安全措施
    1. 反脆弱的组织：1. 超时；2. 断路器；3. 舱壁；4. 隔离
    1. 幂等
    1. 扩展：1. 更强大的主机；2. 拆分负载；3. 分散风险；4. 负载均衡；5. 基于worker的系统；6. 重新设计
    1. 扩展数据库：1. 服务的可用性和数据的持久性；2. 扩展读取；3. 扩展写操作；4. 共享数据库基础设施；5. CQRS
    1. 缓存：1. 客户端、代理和服务器端缓存；2. HTTP缓存；3. 为写使用缓存；4. 为弹性使用缓存；5. 隐藏数据源；6. 保持简单；7. 缓存中毒
    1. 自动伸缩
    1. CAP定理：1. 牺牲一致性；2. 牺牲可用性；3. 牺牲分区容忍性；4. AP还是CP；5. 这不是全部或全不；6. 真实世界
    1. 服务发现
    1. 动态服务注册：1. Zookeeper；2. Consul；3. 构造你自己的系统；4. 别忘了人
    1. 文档服务：1. Swagger；2. HAL和HAL浏览器
    1. 自描述系统

12.总结微服务 ​

    1. 微服务的原则：1. 围绕业务概念建模；.2. 接受自动化文化；3. 隐藏内部实现细节；4. 让一切都去中心化；5. 可独立部署；6. 隔离失败；7. 高度可观察
    1. 什么时候你不应该使用微服务

写在后面 ​

  • pdf书籍、笔记思维导图、随书代码打包下载地址：暂无，后面补上
  • 思维导图在线查看：点击打开
  • 得到电子书地址：点击阅读