前言对于需求频繁变动、业务逻辑复杂的大型项目微服务架构可以支撑团队快速迭代保障版本按时交付。本文是《微服务架构设计模式》第一章完整读书笔记全书以 FTGO 外卖平台为贯穿案例拆解「单体架构痛点→微服务核心逻辑→扩展立方体 X/Y/Z 轴、微服务模式语言、微服务优缺点、DevOps 交付指标」全套基础概念。适合刚接触微服务、分不清单体与微服务适用场景、看不懂扩展立方体的新手。一、案例背景Food to Go (FTGO) 公司核心业务消费者 (Consumer) 使用 FTGO 的网站或者移动应用在本地的餐馆 (Restaurant) 下订单FTGO 会协调一个由送餐员 (Courier) 组成的快递网络来完成订单食品 (Order) 的运送 (Delivery)。这套应用程序使用了多个 Web 服务例如使用 Stripe 管理支付、使用 Twilio 实现消息传递、使用 Amazon SES (Simple Email Service) 发送电子邮件等等。二、单体架构的优势与痛点2.1 单体架构优势开发简单项目结构统一本地一键启动无分布式调用复杂问题。测试、部署成本极低只需要打包一个程序一次发布全量更新。适合初创小型业务业务模型没验证前不需要复杂微服务架构。2.2 单体架构的核心特征与单体地狱单体架构的核心特征整个系统打包为一个程序部署业务做大后开发、测试、发布、扩容都会处处受限也就是书中说的单体地狱。参考图1-2三、微服务的定义与架构3.1 微服务的定义微服务架构的概括性定义是把应用程序功能性分解为一组服务的架构风格。简单说就是把一个完整外卖系统按业务拆成互不干扰、能单独上线的小程序。3.2 FTGO 微服务架构案例每个后端服务都有一个 REST API 和它自己的私有数据库注每一个服务拥有它自己数据库的需求并不意味着每个服务都需要一个独立的数据库服务器每个都可以独立开发、测试、部署和扩展开发人员无法绕过服务的 API 并访问其内部组件。后端服务包括以下内容Order Service: 管理订单。Delivery Service: 管理从餐馆到客户之间的订单派送送餐。Restaurant Service: 维护餐馆有关的信息。Kitchen Service: 管理订单的准备过程。Accounting Service: 处理账单和付款。四、扩展立方体 X/Y/Z 轴类比说明一台服务器电脑 一间厨房应用实例运行起来的程序 厨师会做的事情一样4.1 X 轴扩展水平复制厨师变多ABC 3 个人都会进行接单收钱分配骑手——厨师干的活不变厨师数量增多——用户请求多解决吞吐量。技术实现【启动 2 套完整 FTGO 单体程序】——人变多4.2 Z 轴扩展数据分区厨师分区A 专门服务 a 区客人的请求B 专门服务 d 区客人的请求——厨师还是全能只是各自负责不同顾客——用来隔离租户、用户进一步减轻单个实例压力提升可用性。技术实现【订单服务里实例‑1 处理北京用户实例‑2 处理上海用户。】——分客户4.3 Y 轴扩展功能拆分厨师分工A 只负责接单订单实例、厨师 B只管收钱支付实例、厨师 3只管分配骑手配送实例——把一个全能厨师拆成专职厨师——解决单体代码臃肿、后期维护难。技术实现【拆分成订单、支付、配送 3 种微服务实例】——分工种4.4 扩展策略总结单体阶段仅 X 轴扩容复制整套应用微服务拆分Y 轴完成每个服务独立 X 轴扩容高并发用户场景叠加 Z 轴按用户 / 地区隔离流量。五、微服务架构与 SOA 的异同有不少针对微服务架构的批判观点认为其本质只是 SOA 的复刻不存在全新设计思想。从部分维度来看该说法存在一定合理性微服务与 SOA 同属面向服务的架构风格二者的核心思想一致均采用多服务拆分的形式来构建整套业务系统。如果深入研究就会发现微服务和 SOA 之间巨大的差异如表1-1六、微服务架构的好处使大型的复杂应用程序可以持续交付和持续部署。每个服务都相对较小并容易维护。服务可以独立部署。服务可以独立扩展。微服务架构可以实现团队的自治。更容易实验和采纳新的技术。更好的容错性。七、总结本章通过 FTGO 外卖平台的案例系统性地介绍了从单体架构到微服务架构的演进过程。微服务架构通过功能分解、独立部署和扩展解决了单体架构在大型复杂系统中的局限性。扩展立方体的 X/Y/Z 轴为系统扩展提供了清晰的思路而微服务与 SOA 的对比则帮助我们更深入地理解微服务架构的本质特征。