《微服务架构设计模式》阅读笔记（一）

第1章 逃离单体地狱

1.1 迈向单体地狱的漫长旅程

1.1.1 FTGO应用程序的架构

FTGO，即Food to GO公司，作者虚构出来的一家公司。图1-1是它的架构图。

1.1.2 单体架构的好处

1. 应用开发很简单：IDE和其他开发工具只需要构建这一个单独的应用程序
2. 易于对应用程序进行大柜摸的更改：可以更改代码和数据库，然后构建和部署
3. 测试相对简单直观：开发者只需写几个端到端测试，启用应用程序，调用REST API
4. 部署简单明了：开发者唯一需要做的，就是把可执行文件复制到服务器上
5. 横向扩展毫不费力：可以运行多个实例，由一个负载均衡器进行调度。

1.1.3 什么是单体地狱

过渡的复杂性会吓退开发者

系统本身过于庞大和复杂，以至于任何一个开发者都很难理解它的全部。因此修复，软件中的问题和正确的实现新功能就变得困难且耗时。
更糟糕的是，这种极度的复杂性正在形成一个恶性循环：由于代码库太难于理解，因此开发人员在更改时更容易出错，每一次更改都会让代码库变得更加复杂、更难懂。

开发速度缓慢

因为要跟这些极度复杂的系统打交道，开发人员发现他们日常的开发工作变慢了。这个巨大的项目把开发人员的IDE工具搞得很慢，构建一次应用需要很长的时间，更要命的是，每启动一次都需要很长的时间。这严重的影响的团队的工作效率。

从代码提交到实际部署的时间很长，而且容易出问题

一个月完成几次更新，对于开发人员来说简直就是神话，持续部署更是遥不可及的梦想。
众多开发人员都向一个代码库提交代码更改，这常常使得这个代码库的构建结果出于一个不可交付的状态。当采用分支来解决这个问题时，带来的是漫长且痛苦的合并过程。紧接着，一旦团队完成了一个冲刺任务，随后迎接他们的将是一个漫长的测试和代码稳定周期。
把更改推向生产环境的另一个挑战是运行测试需要很长时间。

难以部署

对应用进行横向扩展时也有挑战。因为在有些情况下，应用的不同模块对资源的需求是相互冲突的，有的模块需要内存，有的模块需要CPU。

交付可靠的单体应用是一项挑战

单体应用的另一个问题是缺乏可靠性，这个问题导致了频繁的系统故障和宕机。系统不可靠的一个原因是应用程序体积庞大而无法进行全面和彻底的测试。缺乏可靠的测试你意味着代码中的错误会进入生产环境。更糟糕的是，该应用程序缺乏故障隔离，因为所有模块都在一个进程中运行。

需要长期以来某个可能已经过时的技术栈

单体地狱的最终表现，也体现在团队必须长期使用一套相同的技术栈方面。单体架构使得采用新的框架和变成语言变得极其苦难。

1.2 为什么本书与你有关

略~

1.3 你会在本书中学到什么

略~

1.4 拯救之道：微服务架构

一方面，训练有素的团队可以减缓项目陷入单体地狱的速度。但是另一方面，他们无法避免大型团队在单体应用程序上协同工作的问题，也不能解决日益过时的技术栈问题。团队所能做的是延缓项目陷入单体地狱的速度，但这是不可避免的。为了逃避单体地狱，他们必须迁移到新架构：微服务架构。

1.4.1 扩展立方体和服务

X轴扩展：在多个实例之间实现请求的负载均衡

X轴扩展是扩展单体应用的常用方法。图1-4展示了X轴扩展的工作原理。在负载均衡器之后运行应用程序的多个实例。负载均衡器在N个相同的实例之间分配请求。这是提高应用程序吞吐量和可用性的好方法。