Medium 微服务策略

微服务架构的目标是帮助技术团队更快、更安全、更高质量的推动产品，服务解耦可以让团队快速迭代，对系统的影响最小。

Medium 是一个大型社交博客平台，由Twitter联合创始人在2012年创办，开始时是一个 nodejs 的单体应用，后来系统越来越复杂，团队不断壮大，在2018年初开始迁移到微服务架构。

微服务的原则

在微服务架构中，多个松耦合的服务在一起工作，每个服务聚焦于一个单独的目的，数据和行为都是高内聚的。

微服务设计的3个重要原则：

• 单一目的

每个服务只关注一个目标，把它做好。

• 松耦合

每个服务对其他服务的了解很少，一个服务的改变不需要其他服务进行变更，服务间的沟通应该只通过服务接口的调用。

• 高内聚

服务封装了相关的行为和数据，如果我们需要构建一个新特性，所有的修改应该只涉及一个服务。

做微服务建模时，我们要遵守这3个准则，这样才能真正发挥微服务的潜力。

如果没有实现“单一目的”，每个服务最终将会做很多事情，整个系统最终就变成了多个单体服务，我们的成本将会越来越高。

如果没有实现“松耦合”，修改一个服务就会影响其他服务，修改后的发布就会复杂、变慢、不安全，可能导致灾难后果，例如数据不一致等等。

如果没有实现“高内聚”，最终的结果就是变成了一个多个混乱的服务构成的分布式单体系统，为了构建一个新特性，必须同时修改、部署这些服务，这将比一个巨大的单体服务更加恐怖。

Medium 的微服务策略

（1）构建具有明确价值的新服务

一定不要为了构建新服务而构建新服务，每次我们构建一个新的服务，必须具有明确的产品价值，或者工程价值。

产品价值表现在能给用户带来好处，工程价值表现在可以使技术团队的工作更好、更快，只有价值优于在 nodejs 单体应用中构建时才决定构建新的服务，否则，继续在nodejs单体应用中修改。

（2）单体持久化存储是有害的

持久化存储建模在微服务建模中是一个重要部分，服务间共享持久化存储是非常简单的方式，但危害极大，我们要尽量避免。

持久化存储涉及到了实现细节，服务间共享数据存储就把一个服务的实现细节暴露给了整个系统，如果这个服务修改了数据格式、添加了一个缓存层，其他服务就要跟着做相应的修改，这就违背了松耦合原则。

如果共享了数据持久化存储，那么例如数据的修改、使用等行为就需要多个服务都各自实现，违背了高内聚原则，如果修改某个行为，其他相关服务都需要修改。

在微服务架构中，一个特定类型的数据应该只由一个服务负责，其他服务应该通过API来调用此服务请求数据，或者仅仅是持有数据的只读副本。

下面看一个实际的例子，比如我们要构建一个新的推荐服务，需要 post 表中的数据。

单体的持久化存储方式：

在单体结构中，推荐服务直接访问 post 表，缺点：

• 缓存会变得很棘手，如果推荐服务共享了单体应用的cache，我们就必须在推荐服务中实现cache的细节，如果推荐服务使用自己的cache，当单体应用更新了post数据时，我们不知道什么时候使cache中的数据失效。
• 如果单体应用决定更换数据库，例如从DynamoDB换成RDS，那么就需要重新实现推荐服务中的相关逻辑。
• 在单体应用中，post数据涉及到复杂的逻辑，例如如何决定一个post是否呈现给某个用户，在推荐服务中就也需要实现这些逻辑。如果单体应用中添加或者修改了逻辑，那么推荐服务也得跟着变。
• 单体服务使用了DynamoDB，那么推荐服务也就被限制在了这个数据库，即使这个数据库并不适合本服务。

在解耦模式中，推荐服务不再直接访问post数据，单体服务负责post实现细节，而且有多种方案可选。

方案A，由一个 post service 拥有 post 数据，其他服务通过其API来访问post数据。

方案B，当post数据发生更新时，单体服务通过消息队列服务通知给推荐服务。

方案C，由ETL管道为推荐服务产生post数据的只读副本。

这3个方案中，推荐服务都可以完全的拥有自己的数据，所以可以灵活的应用，例如cache的实现、选择适合自己的数据库等等。

（3）服务只关注自己的业务逻辑

每个服务应该只关注他自己的工作，最好不要管其他复杂的事情，例如网络、通信协议、部署、监控等等，服务管理相关工作应该与服务实现完全解耦。

• 网络

例如服务发现、路由、负载均衡等等，这些都是运行服务的重要部分，传统方法是提供公众语言库，但不够理想，因为应用需要做所有的集成工作和维护工作。现代化的解决方案是使用 Service Mesh，Medium 使用了 Istio 和 Envoy，构建服务的工程师完全不用关心网络相关的工作。

• 通信协议

不管选择什么技术栈、什么开发语言，选择一个好的RPC方案是极其重要的，RPC方案需要高效、跨平台、较小的开发量，Medium 选择的 gRPC。

基于 HTTP 的 REST+JSON 方案是非常普遍的，但在 server-to-server 的沟通中不是很高效，尤其是需要发送大量请求的情况下，而且没有自动生成的样本代码，我们需要手动实现 server/client 代码。

• 部署

使用一致的方法来构建、测试、打包、部署、管理所有的服务是非常重要的，Medium 的所有微服务都运行在容器中，使用 Kubernetes 编排管理。

Medium 开发了自己的一套系统，来构建、测试、打包、部署服务，每个服务只需要提供基础信息，例如监听端口、build/test/start 命令等，其他事情都由系统来处理。

（4）彻底而一致的监控

监控可以让我们知道系统如何工作，出现问题后可以方便的追踪问题。监控包括日志、性能指标、仪表盘、告警等等。

Medium 刚开始转到微服务时，遇到了2个问题：

1. 由于微服务复杂度高，很难监控，导致系统没有了可监控性。
2. 不同团队对于自己那块儿做监控，重复创造轮子，最终导致监控碎片化，碎片化数据很难连接、归类，可监控性极低。

后来 Medium 使用了 DataDog 服务，实现了自动化仪表盘、告警、日志，还使用了 LightStep 来跟踪系统性能。

（5）尊重失败

我们要经常思考如何做失败测试、如何很好的解决错误。

• 首要一点是随时要有面临出错的意识。
• 对于 RPC，要在处理错误上多做工作。
• 对于失败要可监控。
• 上线新服务时要多做失败测试，整理出检查清单。
• 构建自动恢复机制。

本文翻译整理自： https://medium.engineering/microservice-architecture-at-medium-9c33805eb74f