Python 并发与 asyncio 10.1 微服务

10 微服务

这一章涵盖了

很多网站应用都采用单体架构（monolith）。所谓“单体”，通常指的是一个中等偏大型的应用程序，里面包含了多个模块，这些模块作为一个整体独立部署和管理。虽然这种架构本身没什么问题（对大多数网页应用来说其实挺好的，因为结构简单），但也有它的短板。

举个例子：如果你要改一个单体应用里一个小地方，就得把整个应用重新部署一遍，哪怕其他部分根本没动。比如一个电商系统，订单管理和商品列表可能就在一个程序里，你想改下商品接口，那订单处理的代码也得跟着一起重新部署。

这时候，微服务架构就能派上用场了。我们可以把订单和商品拆成两个独立的服务，这样改其中一个，完全不影响另一个。

这一章，咱们就来深入聊聊微服务，搞清楚它们背后的设计理念。我们会学习一种叫“前端后端”（backend-for-frontend）的常见设计模式，并用它搭建一个电商场景下的微服务系统。然后我们用 aiohttp + asyncpg 实现这个接口，利用异步并发来提升应用性能。最后，还会掌握用“熔断器”（circuit breaker）模式应对故障和重试，让系统更健壮。

10.1 为什么选择微服务？

先来聊聊什么是微服务。这事儿可没标准答案，每个人说法都不一样。不过大体上，微服务遵循几个核心原则：

拿一个电商网站来打个比方：用户在你这儿买东西，得填收货地址和支付信息。在单体架构下，所有数据（用户、订单、商品）都堆在一个库里。而在微服务架构里，你可以分别建产品服务、用户服务、订单服务……每个服务都有自己的数据库，只管自己那一亩三分地。

那为什么要用微服务而不是老老实实做单体？单体确实简单好管：改个代码，全跑一遍测试，没问题就一股脑儿发布。如果压力大了，还能水平或垂直扩展——多开几台机器就行。

但越复杂的项目，单体就越难搞。维护起来费劲，团队之间还容易“互相扯皮”。而微服务恰好能解决这些问题。

10.1.1 代码复杂度飙升

随着功能越来越多，系统会越来越臃肿。数据模型逐渐耦合，莫名其妙的依赖关系越来越多，技术债越积越多，开发效率越来越低。这对大型项目尤其致命。微服务把不同关注点分开，能有效缓解这个问题。

10.1.2 扩展能力差

单体架构要扩容，就得整个应用一起拉起来。比如电商平台，浏览商品的人可能有十万，下单的也就几千。按单体的思路，你得把订单系统的容量也一起扩上去，太浪费了。但如果是微服务，我只扩容商品服务就够了，订单服务闲着也没事。

10.1.3 团队和架构的自由度

团队壮大之后，单体代码库就成了“战场”：谁改代码，谁都得跟别人合并，冲突一堆。各团队还要协调上线时间，鸡飞蛋打。

但要是用了微服务，每个团队负责自己的服务，自产自销，发版基本不用看别人脸色。而且技术栈也能灵活选——有人用 Java，有人用 Python，随便折腾，谁也不拦谁。

10.1.4 asyncio 怎么帮上忙？

微服务之间总得通信，一般是通过 REST/gRPC。我们要同时调好几个服务，这正好是异步编程的用武之地。

不仅资源利用率高，asyncio 的 wait、gather 等 API 还能轻松聚合多个请求的结果，支持优雅地处理超时或异常。一旦某个请求卡住或者报错，可以精准控制，不会让整个服务瘫痪。

讲完了动机，接下来咱就来实战，学一个最常用的微服务设计模式：前端后端。