《微服务设计》

读书笔记 软件工程 DOING

前言

微服务是分布式解决方案

第1章 微服务

领域驱动设计、持续交互、按需虚拟化、基础设施自动化、小型自治团队、大型集群系统

1.1 什么是微服务

微服务就是一些协同工作的小而自治的服务

在一个单块系统内，通常会创建一些抽象层或者模块来保证代码的内聚性，即单一职责原则。微服务将这个理念应用在独立服务上，根据业务的边界来确定服务的边界。

足够小，而不要过小。服务越小，独立性越小，但是管理大量服务也越复杂。

服务之间均通过网络调用进行通信，从而加强服务之间的隔离性，避免紧耦合。需要考虑什么应该暴露，什么应该隐藏。服务会暴露出API，然后服务之间通过API进行通信。

1.2 主要好处

• 技术异构性
  
  • 不同模块可以采用不同的技术栈
  • 可以容易修改与重构
• 弹性：通过将同样服务部署到多个机器上达到处理服务不可用和功能降级问题
• 扩展：可以针对需要扩展的微服务进行扩展（优化、增加运行机器、添加特性等）
• 简化部署：各服务部署是独立的
• 与组织结构想匹配
• 可组合性：可以与各种前端配合
• 对可替代性的优化：微服务很容易被替换

1.3 面向服务的架构

SOA是一种设计方法，其中包含多个服务，而服务之间通过配合最终会提供一系列功能。

1.4 其他分解技术

• 共享库
  
  • 不能使用异构技术
  • 失去对某一部分的独立扩展能力
• 模块
  
  • OSGI 复杂性太大
  • Erlang 语言内置支持模块

第2章 演化式架构师

2.1 不准确的比较

2.2 架构师的演化视角

软件中我们面临大量的需求变更。我们应该设计出一个合理的框架，在这个框架下可以慢慢演化出正确的系统。更接近城市规划师，模块划分。

2.3 分区

考虑不同的服务之间如何交互，或者说保证我们能够对整个系统的健康情况进行监控。

2.4 一个原则性的方法

• 战略目标：通常不需要我们来定义
• 原则：用来约束和指导系统的演化
• 实践：应该巩固原则，包括代码规范、风格、限制等
• 将原则和实践相结合

2.5 要求的标准

• 监控：系统级别描绘出跨系统服务的健康状态
• 接口
• 架构安全性

2.6 代码治理

• 范例
• 裁剪服务代码模板

2.7 技术债务

理解债务的层次和其对系统的影响非常重要

2.8 例外管理

2.9 集中治理和领导

2.10 建设团队

2.11 小结

第3章 如何构建服务

3.1 MusicCorp简介

3.2 什么样的服务是好服务

专注两个重要概念上：松耦合和高内聚

• 松耦合：修改一个服务不需要修改另外一个
• 高内聚：把相关行为聚集在一起，不相关行为放在别处，修改时改动才小范围

3.3 限界上下文

每个限界上下文的东西可以分成两部分，一部分不需要与外界通信，一部分需要。

限界上下文：一个由显式边界限定的特定职责。

• 共享的隐藏模型
• 模块和服务：识别限界上下文后，使用模块进行建模，同时使用共享和隐藏模型
• 过早划分

3.4 业务功能

思考限界上下文时，不应该从共享数据的角度来考虑，而应该从这些上下文能够提供的功能来考虑

3.5 逐步划分上下文

• 嵌套的上下文不直接对外可见
• 将所有的服务提升到顶层（去掉之前的顶层）

3.6 关于业务概念的沟通

3.7 技术边界

层次边界划分错误，会导致到处都会进行修改

3.8 小结

第4章 集成