Spring Cloud 讲解前言：传统单体项目和微服务

更多原创文章，请访问：https://takioo.cn

早期的传统项目和现在的微服务架构项目

1. 先举例一段生活中的场景

小餐馆初期只有一个厨师，切菜洗菜炒菜端盘全部一个人负责，（传统的单体服务）后来客人多了（访问量剧增/业务需求以及复杂性增加），一个人忙不过来，就又请了三个伙计，分别负责切菜、洗菜、端盘（服务拆分，演变为微服务架构），这样厨师就可以专心只负责炒菜，目前为止，总共四个服务模块：切菜–洗菜–炒菜–端盘。 有一天，老板发现客人中有很多四川人，于是想增加一些川菜，又招了一个四川大厨（炒菜服务模块的扩展，体现微服务的易扩展性）。

饭店生意变得更大了，陆续又招了几个厨师，分别负责炒鲁菜、川菜等。因为厨房与前台隔离，如果来了一个客人要点一个川菜，四川厨师也不知道，这时候就需要一个充当中间传话人作用的伙计（服务注册中心）。一开始，厨师们都到这个中间人那里登记自己的信息，譬如四川厨师登记：我是四川厨师，编号1111，负责炒四川菜（服务注册）。这样就方便多了，来了个客人点了个川菜，传话的伙计看了看登记表，拿起传话机告诉四川厨师：大厨，麻烦炒个麻婆豆腐。– Spring Cloud Eureka

后来，饭店越做越大，专门负责炒四川菜的厨师一个人也忙不过来了，于是老板又招了个四川厨师进来，为了便于区分，暂且称这两位四川大厨为A厨师和B厨师（集群模式）。如果好几个客人都同时点了四川菜，这时需要一个来分配任务的中间人（负载均衡器），他负责来给A、B分配。如果A厨师效率较高并且炒出来的同样也很好吃，那么分给A的数量就多些（采用权重算法分配）；如果A、B水平相当，那么就轮流分配（采用轮询算法分配）。– Spring Cloud Ribbon

结合上面的场景，估计大家对微服务应该有了一些基础概念。

2. 传统的单体项目：

结构：数据库–服务端–前端展示，所有的业务逻辑均在一个应用中。

2.1 传统项目的不足：

业务需求的不断增加，单体应用变得臃肿且不易维护，通常是一挂全挂；并且随着移动端设备的出现和发展，前端展示模块已经不仅仅局限于web形式，移动端对接口的需求量也使得应用更加复杂。

3. 微服务架构：

将原本独立的一个系统拆分成多个小型服务，服务之间通过基于HTTP的restful API进行通信协作，这些小型服务各自维护着自身的数据存储、业务开发以及独立部署机制等。

3.1 优点

耦合度降低、单个服务系统可独立开发部署、易于扩展、复用性更强、开发效率提高，项目结构清晰。

3.2 缺点

• 服务增多，运维需要维护的进程数量增加，部署工作量增加。
• 服务间的调用，可能收到网络延迟、故障等的影响，需要考虑系统的高可用。
• 分布式事务导致系统测试和服务调用链的跟踪难度增加。

Spring Cloud 是一个基于Spring Boot 实现的微服务架构工具，是一个庞大复杂，又不失优雅的框架，它不像其他的框架，只能解决微服务中的某一个问题，而是一个能够解决微服务架构综合性问题的框架，这也是Spring Cloud 对诸多开发团队具有很强吸引力的魅力原因。

开篇贴合生活中的两种场景来简单阐明了Spring Cloud 中的两个子项目（Eureka、Ribbon）能够解决微服务中带来的两种问题（多服务间的通讯、负载均衡问题）。后续的文章会更加详细的介绍这些框架的使用。