《微服务设计》读书笔记

第1章 微服务

微服务定义

微服务并没有准确的定义，一般，我们把一些协同工作的小而自治的服务称为微服务。通过这个约定俗称的定义，我们可以知道微服务的两大特点：1）小；2）自治

• 小，专注做好一件事
  在传统的单体应用中，一个服务的代码量往往是非常庞大的，相似功能代码随处可见，给bug修复和新功能开发带来了很大的困难。为了保证内聚性，单体应用中会创建一些抽象层或者模块。但微服务直接将这个概念应用到了独立的服务上，根据业务边界来确定服务边界。由于该服务很好的专注于某个边界之内，因此可以很好的避免服务代码量的逐步增长。
  但是，微服务的小也没有一个统一的定义，更多的是需要结合具体业务、具体开发语言和具体依赖等其他因素得到的一个经验值。澳大利亚的Jon Eaves认为，一个微服务应该在两周内重写完。
• 自治性
  一个微服务就是一个独立的实体。它可以独立的部署在PaaS上，也可以作为操作系统的一个进程存在。服务会暴露出API，服务间通过API进行通信，从而加强服务间的隔离性，避免了紧耦合。
  这些服务应该可以彼此间独立的修改，并且某一个服务的部署不应该影响其消费方服务的变动。

微服务的主要好处

1. 技术异构：可以在不同的服务中选择最合适该服务的技术
2. 弹性：可以很好的处理服务不可用和功能降级问题
3. 面向扩展：可以局部的扩展部分服务的功能，而不对整体产生冲击
4. 简化部署：服务之间可以独立部署，即使出了问题，也只会影响个别服务
5. 与组织架构相匹配：服务的所有权可以在团队间转移，从而避免异地团队的出现
6. 可重用、可组合：可以对已有微服务的组合来实现更大的应用
7. 对可替代性的优化：重新实现某个微服务或者直接删除该服务都是相对可操作的

微服务的不足

1. 微服务是分布式应用，具有分布式具有的复杂性
2. 分区数据库架构带来的最终一致性，比单体应用的数据库一致性实现难度更大
3. 测试更加困难，测试某服务时需要启动其依赖服务（至少需要这些服务的桩代码），如消息组件
4. 对于波及多个微服务的改变，更新顺序与服务间的依赖关系相关联
5. 需要提供大量微服务的注册和发现机制

面向服务的架构

SOA（面向服务的架构）是一种设计方法，其中包含多个服务，服务之间通过配合提供一系列功能。一个服务通常以独立的形式存在于系统进程中。服务之间通过网络调用，而非采用进程内调用的方式通信。
SOA和而微服务架构之间没有明显的界限，可以认为微服务架构是SOA的一种特定方式。

第2章 演化式架构师

架构师的演化视角

在软件中我们会面临大量的变更需求，使用的工具和技术也具有多样性。我们创造的东西并不是在某个时间点之后就不再变化了，甚至发布到生产环境之后，软件还能继续演化。因此，架构师必须改变那种从一开始就设计出一个完美产品的想法，相反我们应该设计一个合理的框架，在这个框架下可以慢慢演化出正确的系统。
要求的标准

1. 能够清晰的描绘出跨服务系统的健康状态非常重要，这必须在系统级别而非单个服务级别考虑
2. 选用少数几种明确的接口技术有助于新消费者的集成
3. 必须保证每个服务可以应对下游服务的错误请求、返回码遵循一定的规则

技术债务

有时候可能无法完全遵循技术愿景，比如为了发布一些紧急的特性，你可能会忽略一些约束。其实这仅仅只是另一个需要做的取舍而已。我们的技术愿景有其本身的道理，所以偏离了这个愿景短期可能会带来收益，但长期来看是要服务代价的。可以使用技术债务的概念来帮助我们做这个取舍。

第3章 如何建模服务

什么样的服务是好服务

好的微服务的核心原则：高内聚、低耦合

• 高内聚
  我们希望把相关的行为聚合在一起，把不相关的行为放在别处。这样，当需要修改某个行为的时候，只用修改一个地方，然后就可以尽快的发布。如果需要修改多处，则可能需要修改、发布多个微服务，这样的操作风险是很高的。所以，找到问题域的边界很重要。
• 低耦合
  如果做到了服务之间的松耦合，那么修改一个服务就需要修改另外一个服务。一个松耦合的服务应该尽可能少的知道与之协作的服务的信息。这也意味着，应该限制不同服务之间的调用形式的数量，因为除了潜在的性能问题外，过度的通信可能会造成紧耦合。

限界上下文

Eric Evans在《领域驱动设计》一书中引入了一个很重要的概念：限界上下文（bounded context）。他认为每个给定的领域都包含多个限界上下文，每个限界上下文中的东西分为两部分，一部分不需要与外部通信，另一部分则需要。每个上下文都有明确的接口，该接口决定了它会暴露哪些模型给其他的上下文。
在本书中&#x