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

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

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)能够解决微服务中带来的两种问题(多服务间的通讯、负载均衡问题)。后续的文章会更加详细的介绍这些框架的使用。


版权声明:本文为博主原创文章,欢迎转载,转载请注明作者、原文超链接。
✿ 获取更多,请戳这儿

Comments
Write a Comment