项目架构演变【小白易于理解版】

项目架构的演变

项目架构就是一个项目的组成结构
举个栗子：
一个公司会有各个部门，例如秘书部、采购部、财务部…，各个部门之间互相有联系（毕竟每个人都要去找财务要工资啊 TAT）
所有部门组成了整个公司
而项目也是如此，一个项目由多个模块组成，各个模块之间相互调用
模块之间的关系以及如何划分模块，就是项目架构

单体架构

最简单也是最原始的项目架构
所有模块均放在一起（挤在一起真暖和）

举栗子时间到：
电商项目
抢购、下单、物流查询等等模块全部放在一个服务器上
互相调用很方便，直接调用某个模块的提供的方法/函数即可
这就是单机单体架构
但是明眼人就能看到风险：服务器一旦崩溃，全部完蛋！！！

所以就需要多个服务器来规避风险：将ABCD所有模块再部署到另一个服务器上

app1挂了，还有app2
这就是多机单体架构
优点：

• 简单，开发和部署方便。是小型项目首选
  一个项目就输出一个hello World，也不至于去分层分模块

缺点

• 项目启动慢
  一个项目包含辣么多模块，整体启动当然慢。

就好像你夏天起床和冬天起床，一个穿的少，一个穿得多，肯定冬天起床慢啊

• 可靠性差
  各个模块之间相互联系，若一个模块出错，其他模块也不能正常运行

ps：A对B说：我喜欢你，B说：我喜欢C，C说：我喜欢D，D说：我喜欢A（好乱）

• 伸缩性差
  别想太多，不是你想的那种伸缩
  某个模块需求量大，那么就需要再增加一个该模块
  但是单体结构中，各个模块都挤在一起，互相联系，没办法独立升级（ABCD：我们是一个整体，别想分离我们！！！）

例如：双十一期间，下单需求量大，那么下单模块就需要多增加，称为“伸”；等下完单，需求量变少，就需要减少，称为“缩”
伸，可以理解为春运时临时增加的售卖火车票窗口，可以将客流量均匀分布到各个窗口
但是单体架构中，所有客流量都是直接调用一个窗口的售卖方法。这种情况下，如果增加了多个窗口，就需要对所有买票请求进行控制，将其分发给各个窗口，确保所有请求不会去到同一个窗口，即 负载均衡。很显然，单体架构不具备

• 可扩展性、可维护性差
  扩展和伸缩差不多，扩展是加一个新模块
  因为ABCD是一个整体，若加入一个新模块，将会改动很多东西
  因为ABCD分界线不明显，业务互相联系、纠缠，当出现一个问题时，无法很快定位问题的原因，并且后期维护，还要考虑改动的位置会不会影响其他模块

例如，一个部门，既要做前端开发，
又要做后端开发。当你要加入一个项目经理时，就需要和这个部门进行任务交接。之前人家一个部门说干就干，现在不行了，得听项目经理安排了（原来直接调用另一个模块的方法，现在需要先调用新模块，再决定是否调用）

---

A：这怎么能是我的问题？我可是就调了一下B的方法！
B：A确实调了我的方法，但是我还调了C的方法呢！
C：……，程序员：你们不用说了，是我的问题

---

A：你改动我，得先问问B； B：你改动我，得先问问C……
程序员：我不改了 TAT

• 性能低
  这个就不用解释了吧，模块多，还都挤在一个服务器上，性能肯定会低哇

垂直架构

垂直：专注于某一个领域
例如：说起淘宝，只能想到是卖东西的；而说起京东，可以想到是卖家电3C的；京东就是在电商领域的垂直

垂直架构就是让某个模块专注干一件事，将多个模块拆分成多个独立的单体结构
AB和CD之间没有任何联系，两者可以独立运行
就好像下单和查物流两个模块没有联系，就可以分别部署在两个服务器上
解决了单体架构的一些缺点：项目启动慢、可伸缩性差……
但是也有自己的缺点：

• 重复功能太多
  每个独立模块都需要重写一遍，若重复的功能需要改动，每个包含它的独立模块都需要改

下单：需要知道是哪个用户下单
查物流：需要知道是哪个用户的物流信息
它们都需要调用 用户管理模块，即上图的E
而如果用户表发生结构变化，例如增加一个字段，那么在AB和CD模块中的E就需要改动

分布式架构

既然E是两个模块都要用的服务，那就提取出来，作为 公共服务
但是提取出来之后，就不能像以前调方法似的调用E了。都没有部署到一个tomcat中，自然就无法通过方法去调用
（分家了还想动动嘴就指使人，不可能！！！）
此时可采用RPC进行调用（婆婆：我可以电话使唤你啊 ^^_^）

RPC（Remote Procedure Call）远程过程调用
是一个概念，具体的实现有多种方法：HTTP REST风格、Java RMI规范、WebService SOAP协议、Hession等

这种调用方式，AB和CD模块是 服务消费者，E是 服务提供者。
其可以有效解决代码重复问题。不过虽然解决了代码重复的问题，但是一波未平一波又起啊
例如：E的IP是192.168.10.1，AB和CD模块去访问，肯定是访问该IP
但是当E的IP发生变化，那么AB和CD模块都要跟着改……
于是就有了后面的架构

你（服务消费方）拿着刚办的健身年卡，根据上面的地址来到一片废墟（内心os：我是不是被骗了？）

SOA架构

于是提出服务的提供方和消费方不进行直连，而是通过中间件ESB连接
提供方每次更改地址，都需要告诉中间件新地址
消费方去找中间件要某个提供方的地址，然后进行连接

ESB：(Enterparise Servce Bus) 企业服务总线，服务中介。主要是提供了一个服 务于服务之间的交互。ESB包含的功能如：负载均衡，流量控制，加密处理，服务 的监控，异常处理，监控告急等等
健身房：你没有被骗，我们只是搬家了，下次你再来，打客服（ESB）问我们最新的地址就行

微服务架构

微服务架构和SOA架构几乎相同，是对SOA的一个升华
微服务架构强调：业务需要彻底的组件化和服务化
即将之前的一个模块拆分成各个独立的微服务，每个微服务均可以独立运行

图中，ABC是三个微服务，有自己的数据库，互不影响，均可独立运行
客户端通过访问一个独立服务（网关），由该服务对请求进行分发（决定用户具体访问ABC哪个服务）
特点

• 服务实现组件化
  各个模块的开发语言可以不相同，毕竟是通过http调用，又不是方法调用
  也不需要协调其他团队，一个模块的开发不需要任何外人指手画脚，嘿嘿
• 去中心化
  每个微服务有自己私有的数据库持久化业务数据
  不像以前，多个服务模块共用一个数据库
• 自动化部署
  把应用拆分成一个个独立的单个服务，方便自动化部署、测试、运维