《微服务架构设计模式》第一章

逃离单体地狱

FTGO单体架构

​​​​​​​作者用国外FTGO公司（一家做线餐饮外卖）的应用程序举例，阐述了单体架构的优缺点。FTGO应用架构如下：

应用程序是单体应用，具有六边形架构，最内侧是业务逻辑，包含订单管理、配送管理、用户管理等。业务逻辑外边是实现用户界面的适配器和与外部系统对接的适配器。外部系统如：消息服务、邮件服务、支付服务、数据库。通过这些适配器，业务逻辑可以访问数据库，调用外部服务。

单体架构的好处

1. 应用开发简单：只需要构建这一个应用就可以了。
2. 易于大规模的更改：可以更改代码和数据库模式，然后构建和部署。
3. 测试相对简单直观：只有这一个应用，测接口或者使用Selenium就行了，Selenium是一个可以控制浏览器的工具。
4. 部署简单：部署时开发者唯一要做的把WAR文件复制到安装了tomcat服务器上。
5. 横向扩展不费吹会之力：可以运行多个实例，有一个负载均衡器进行调度。这里提一下什么是横向扩展和纵向扩展：
   横向扩展和纵向扩展都是一种架构理念。
   横向扩展是向环境中添加机器或节点，如给服务新增一台机器/节点，给mysql新增个从库等，各个节点共同完成。众人拾柴火焰高
   纵向发展是提高单个节点的处理能力，如给mysql增加内存、提升机器cpu性能等。注重个人发展，个人能力顶呱呱

单体架构的坏处

1. 过度复杂性吓退开发者：系统庞大复杂，开发者很难梳理出其中逻辑，更改或新增功能时，困难又耗时，这种情况随着每一次开发会越来越糟糕，有点像业内说的“堆shi山”，哈哈哈。
2. 开发速度缓慢：系统太庞大，构建、启动、测试、部署花费的时间会越来越长，严重影响开发效率。
3. 难以扩展：这里的扩展是指系统提供的功能越多，就需要越多的资源。如内存、cpu、gpu。一般的服务器满足不了，得需要高性能的服务器。
4. 交付不可靠：一个模块出了问题，整个服务就可能故障或宕机。容易出问题的其中一个原因就是因为系统过于庞大而无法进行全面的测试。

拯救之道:微服务架构

微服务概念

Netfix著名架构师将微服务定义为面向服务的架构，由松耦合和具有边界上下文多的元素组成。作者描述了一个三维可扩展模型来更好的说明

X轴：复制实例，并实现负载均衡，提高吞吐量和可用性。没啥好说的。属于上边提到的横向扩展了。

Y轴：根据功能把应用拆分成服务。降低应用复杂性。

Z轴：根据请求的属性就行路由请求，每个实例负责数据的一部分子集。如查询用户信息，根据useId将请求路由到对应实例。

---

微服务的一个关键特性就是每个服务之间都是松耦合的，仅通过API进行通信，实现松耦合的方式之一就是每个服务都有自己的私有数据库

FTGO微服务架构

将单体应用拆成订单管理、配送管理、餐馆管理、用户管理等服务。每个服务和API都有着其清晰的定义，有着独立数据库，也可以独立开发、部署、扩展

微服务好处

1. 大型的复杂应用程序可以持续交付和持续部署，是微服务最大好处
2. 每个服务相对较小，易维护、可独立扩展、部署、容错性高，可实现团队自治。巴拉巴拉…

微服务弊端

微服务并不是一种银弹（类似一种特效武器），不是说用微服务就可以解决软件中所有问题了。

1. 服务拆分和定义是一个挑战。如何拆分和定义确实需要考虑好。不然可能拆分成一组耦合度很高的微服务架构。
2. 分布式系统带来的复杂性。一个服务变成了多个了，那么服务之间就需要通信了。这比一个服务调用本地方法要复杂，需要考虑远程服务不可用或高延迟情况，做故障处理。开发的时候要打开多个应用了，测试的时候之前要部署一个应用，现在可能要部署多个了。如果应用不属于同一个团队，部署钱要和其他团队沟通好。
3. 什么阶段使用微服务？刚开始开发一个项目，需要快速迭代的时候，精心设计分布式架构会减缓开发速度。当问题复杂的时候，就需要将应用程序分解成一组服务了。但如何将重构复杂的应用程序，也是一个问题。