随笔

终于迎来了“微服务、云原生”系列文章，这个系列的文章的更新速度博主无法保证能够每个星期一篇，因为这个系列的难度比以往系列都要高（以往的系列就没有保证一个星期一更）。但是长时间不去写文章，自己可能会慢慢失去写作的能力与热情，因此，除了“微服务、云原生”系列的文章，博主会穿插“mysql”系列的文章。

参考书籍：

1. “凤凰架构”
2. 微服务架构设计模式

单体架构（Monolithic）

“单体”只是表明系统中主要的过程调用都是进程内调用，不会发生进程间通信，仅此而已

对于单体架构（又称巨石系统（Monolithic Application）），各位应该都不会太陌生，，可以说在“微服务架构”出现在大家的视野之前，市面上基本都是单体架构的软件。而单体这个概念其实是在“微服务”理念提出后所产生的，从概念诞生的先后顺序，我们也不难看出，“单体”与“微服务”是一组相互对比参照的概念。

我们深入了解单体架构之前，大家先思考一个问题：“单体架构是不是一种优秀的软件设计？”

可以不用着急下结论，深入了解单体架构之后再看这个问题，你会有不一样的感受。

下图是“微服务架构设计模式”中用来举例的单体项目架构：

这个应用的名字叫FTGO（Fod to Go的简称），核心业务为消费者 (C o n s u m e r ) 使用 F T G O 的网站或者移动应用在本地的餐馆 (R e s t a u r a n t ) 下订单， F T G O 会协调一个由送餐员 (C o u r i e r )组成的快递网络来完成订单食品(Order)的运送(Delivery)。

FTGO应用程序具有六边形架构。它由业务逻辑组成，业务逻辑外面是实现用户界西的适配器和与外部系统的接口，例如移动应用程序，支付、消息和电子邮件的云服务等（这种应用层面的架构设计是没有什么问题的，符合高内聚、低耦合等软件设计理念，可以称得上一个好的设计）。同时，这个应用会被整体打包成一个单一的WAR 文件，部署运行在Tomcat 之上（很典型的单体软件架构风格）。

听到这里，大家对这个系统应该是有一个比较直观的感受就是：如果系统业务非常的复杂，这个系统后期的war肯定非常的滴大。如果项目在我的ide上跑，可能索引就需要好几个小时，更不用说编译和运行了（博主亲身经历过🥹）。按照大家98年的脾气，可能刚进公司就已经准备跑路了～～

结合软件历史来说，这种系统架构在当时已经是最优选（此时还没有微服务这种概念），使用这种架构的软件系统在发展的早期，应用程序相对较小，会有以下好处：

1. 应用的开发很简单：IDE和其他开发工具只需要构建这一个单独的应用程序（开发初期，后期如果业务复杂，此优势将不负存在）
2. 易于对应用程序进行大规模的更改：可以更改代码和数据库模式，然后构建和部署。
3. 测试相对简单直观：开发者只需要写几个端到端的测试，启动应用程序，调用RESTAPI ， 然后使用 Selenium 日这样的工具测试用户界面。
4. 部署简单明了:开发者唯一需要做的，就是把WAR文件复制到安装了Tomcat的服务器上。
5. 横向扩展不费吹灰之力：FTGO可以运行多个实例，由一个负载均衡器进行调度

上面这么多优点，都是针对于项目初期来说的，随着时间的推移，整个系统的开发、测试、部署和扩展都会变得更加困难。至于为什么，我们接着往下面看。

上图是FTGO项目从开发到部署的一个整体流程，分析这个过程我们其实不难找到一些问题：

1. 业务过于复杂导致开发人员难以理解系统的全部（校招员工：进公司两个月，我们公司的系统是干什么的？）
2. 开发速度缓慢（员工：ide打开项目、编译、运行如果只要2分钟，那我开发速度肯定高）
3. 从代码提交到实际部署的周期很长，而且容易出问题（开发：如果我头发还顶的住，那么我能够在指定时间内开发完。 项目测试：我测试一个功能最少需要2天，前提是开发写的代码没问题。 运维：我部署项目需要1天，前提是服务器配置高）
4. 难以扩展（订单团队：我们模块是核心模块因此服务需要占用大量系统资源没问题吧 图片处理团队：我们功能需要比较快的CPU 来完成图形运算也是合情合理的）
5. 交付可靠的单体应用是一项挑战（某开发人员：我艹，上回写的需求里面有一个OOM的bug，P0级故障，我要准备跑路了 ）
6. 需要长期依赖某个可能已经过时的技术栈（技术大牛： shit，我Golang白学了）

如果单从FTGO项目来分析单体架构，我们眼里看到的更多的是单体架构的不足。但是需要知道的是，在微服务架构出现之前，基本所有的公司都用的单体架构，如果单体架构那么不堪，怎么可能会有那么多企业的架构师会选择采用单体架构进行项目的开发呢？也就是说，衡量一个架构的好坏不能单靠一个案例就可以决定的。

假设现在公司想让你做一个业务相对简单的系统，你会选用单体架构还是微服务架构？

如果是我的话，我会首选单体架构，至于为什么，我从一下几个角度进行说明：

1. 纵向角度（MVC分层架构）：对于这个意义上的“可拆分”，单体架构完全不会展露出丝毫的弱势，反而可能会因更容易开发、部署、测试而获得一些便捷性上的好处。
2. 横向角度（物理加服务器）：单体架构也可以支持按照技术、功能、职责等维度，将软件拆分为各种模块，以便重用和管理代码。单体系统并不意味着只能有一个整体的程序封装形式，如果需要，它完全可以由多个 JAR、WAR、DLL、Assembly 或者其他模块格式来构成。即使是以横向扩展（Scale Horizontally）的角度来衡量，在负载均衡器之后同时部署若干个相同的单体系统副本，以达到分摊流量压力的效果，也是非常常见的需求
3. 服务的性能消耗角度：一台服务器就可以满足业务需求
4. 人员角度：开发此系统的开发人员规模没有超过“2 Pizza Team”的范畴
5. 业务层面：业务简单，不需要进行业务拆分