![字母哥博客](https://cdn.zimug.com/wx-zimug.png)
微服务近些年可谓是发展的如火如荼,和别人谈技术不聊点“微服务”,会让自己感觉很落伍。很多人聊微服务,但真的把微服务聊的通俗、聊的通透的人并不多。
我想以一种非常通俗的方式和大家解释一下微服务,就是以“夫妻摊位”到“五星饭店”发展的角度为例,为大家说明一下微服务及微服务所解决的问题,带来的挑战。
## 第一阶段:夫妻摊位
小夫妻俩刚结婚,手里资金有限,就想着开一个路边烧烤摊。丈夫负责烤串做菜、妻子负责服务收银及上菜。这是一个典型的路边烧烤摊的经营模式。大家仔细看这种经营模式的好处在于:
* 因为摊位的桌椅板凳的容量通常是有限的,所以食品总的需求量的上限也基本是固定的。 这种摊位很少会出现长时间的等菜的现象。
* 沟通顺畅、快速,这头点菜点串吼一嗓子、那边就开始做上了。做好了再吼一嗓子,就上菜了。
* 短小精悍、容易掉头。夫妻两有可能干一阵发现这个位置客流少或者只赚辛苦不赚钱,就可以立刻停止经营、换个地方经营或者找别的营生。
这个阶段就有点像一些创业公司,刚开始创业的时候,一般做的应用都是单体应用。笔者也见过一些创业公司,上来就想搞微服务,我觉得这是不太现实。企业的架构都是一步一步衍进的,不要总想着一口吃一个胖子。如果京东淘宝从第一天做应用的时候就想做成今天的样子,他们一定活不到今天。就像一个没开过饭店的人第一次创业就要开五星级饭店,等待他的十有八九就是失败!
那么单体应用的特点有哪些:
* 能够接纳的请求数量时有限的,因为服务器的内存、CPU配置是有限的。
* 展现层、控制层、持久层全都在一个应用里面,调用方便、快速。单个请求的响应结果超快。
* 开发简单、上手快、三五个人团队好管好用。老板决定不干了,随时可以掉头,基本不太肉疼。
![](https://img.kancloud.cn/50/db/50db3a3509d1c530503d1554564fda00_1133x270.png)
## 第二阶段:门面饭馆
但是,随着小夫妻俩经营有方、待客有道,开始有人愿意为了吃他们做的烧烤排队了。夫妻俩一想,我们这俩人也干不过来啊,怎么办?招人吧、扩大规模吧。
* 招什么人?当然是厨师啊、端菜收银的妻子自己还能干得过来,主要是丈夫的活挺不住了。那就招厨师。
* 不能让人站着吃吧?租一个附近的门市、添置更多的桌椅板凳。
**客户端负载均衡与服务端负载均衡是什么?**
* 小夫妻两一口气为饭馆配置了三个厨师(含丈夫),这下可够用了。妻子将单号订单给张厨师、双号订单给李厨师,两人都干不过来了,再将订单给丈夫。反正外人不用白不用,自己家人能歇会就歇会。**这种模式就是“客户端负载均衡”**,所有的订单全都记在“妻子”的脑袋里,她说给谁就给谁。
* 有一天这俩厨师提出意见:太累了,要么丈夫多出力,要么涨工资。夫妻俩一合计,还是丈夫多出力吧。那妻子也就没有必要记住“订单的单双号”了,所以就使用一款app,妻子输入顾客订单,该app可以实现订单的均衡分配给厨师。**“这种模式就是“服务端负载均衡””**,该app就是负载均衡器,常用的软件负载均衡器有nginx、haproxy等。还有一些硬件的负载均衡器,性能上要更好一些,当然收费也更“好”。
![](https://img.kancloud.cn/81/3a/813a94406fd75a4dc63a7a3a3d65be37_871x664.png)
**利与弊**
* “利”就是应用的处理能力增加了,能够处理更多的订单。
* “弊”就是沟通成本增加了,原来吼一嗓子解决的问题,现在需要app转发了(负载均衡器)
也就是说:饭店(应用)现在在处理并发请求的能力和容量上增强了,但是在单个请求的处理速度上下降了。实际上,这就是服务拆分,服务拆分就是在 **“用时间换空间”** 。你细品!
## 第三阶段:核心分工精细化
为了解决上一阶段遇到的问题:单个请求的处理速度下降。也就是饭店针对单个订单做菜响应速度下降了,但是由于饭店的菜确实好吃、菜品精良,客流量又持续的增高。该店又再次面临扩容的问题。
* 为了解决客流量持续增高,夫妻又招聘了4位厨师
* 为了解决单个订单处理速度下降的问题,将厨师分为两组,一组专门做烧烤,一组专门做饭菜。专业的人做专业的事情,注意力越集中,办事越熟练、效率越高。
新的问题又出现了,有的顾客既点烧烤又点饭菜。导致后端两组厨师之间沟通不畅,怎么组合套餐推送给前台?厨师之间怎么调用、怎么沟通啊?谁是头?谁是大脑?谁记得A厨师的烧烤和B厨师的饭菜是一桌的?
![](https://img.kancloud.cn/6c/1b/6c1b238804854e172de59aeaf66c810a_921x595.png)
丈夫一看这种情况,我也别再做厨师了,那做什么?做菜品的配置管理、做订单的服务注册。丈夫负责主动观察问询各工种的工作状态并记录,妻子主动向丈夫问询后端厨师的状态,并根据丈夫的反馈分配订单(客户端负载均衡)。丈夫的新工作实际上就产生了微服务非常重要的组件:服务注册中心和配置管理中心。比如:Spring Cloud Alibaba nacos、eureka、consul、zookeeper、Spring cloud config等
## 第四阶段:配套管理专业化
![](https://img.kancloud.cn/26/8a/268a5c8b7ee4ee78bbc8e3dbd8935e8f_707x549.png)
* 需要有统一的门面了:前台。所有的顾客进来,由前台统一接待。比如:Spring Cloud Gateway和zuul。
* 需要有安保人员了:档次高了、进入饭店有预约。最起码得尊重用餐礼仪,不能是背心裤衩大跨栏,否则就不让你进。比如:OAuth2 认证服务器和资源服务器。
* 菜品限量提供了:法式菜品、意大利菜品、日本料理。什么时间可以吃得到、可提供多少人份?这些服务都是有限制的。比如:Hytrix熔断限流。
* 工作效率监督:工作流程中每个岗位做了什么工作、用了多长时间。哪个环节出现问题、哪个岗位需要调整。比如: Sleuth、Zipkin、日志监控ELK等。
## 第五阶段:容器化、自动化
饭店的规模越来越大了、岗位分工也越来越细了。真的成了超级大饭店了,怎么管?这就需要专业的机器人服务租用公司,这种公司专门出租各种行业专用机器人。
* 服务员统一包装:用自动点餐机、机器人。身高必须一米65,微笑必须漏出四颗牙。
* 物料统一包装:也不用人了,流水作业,一盘菜几块肉、什么料全都自动化配置好。厨师就负责炒熟就行了(拜托,这例子理解就好,不要抬杠)
总之全都自动化。这时公司内部的devops团队就出现了,制定规范、集体包装、流程自动化。突然有一天,饭店承接了大型运动会大型展览,怎么办?要去招服务员么?招员工培训么?不要,租机器人就行了,用完了就还回去。每年的双十一、淘宝京东也都是用容器自动化扩容的方式应对暴涨的服务需求。容器化最大的好处就是:轻量级的发布于与销毁、自动化的扩容。
* 这里的机器人公司,我们可以认为是kubernetes、mesos、swarm
* 这里的机器人,我们可以认为是docker、containerd等
- 文档内容简介(一定要看)
- 笔者的其他作品推荐
- vue深入浅出系列
- 手摸手教你学SpringBoot2.0
- Spring Security-JWT-OAuth2一本通
- 实战前后端分离RBAC权限管理系统
- 模块与代码分支说明
- dongbb-cloud项目核心架构
- 微服务架构进化论
- SpringBoot与Cloud选型兼容
- Spring Cloud组件的选型
- 单体应用拆分微服务
- 单体应用与微服务对比
- 微服务设计拆分原则
- 新建父工程及子模块框架
- 通用微服务初始化模块构建
- 持久层模块单独拆分
- 拆分rbac权限管理微服务
- Hello-microservice
- 构建eureka服务注册中心
- 向服务注册中心注册服务
- 第一个微服务调用
- 远程服务调用
- HttpClient远程服务调用
- RestTemplate远程服务调用
- RestTemplate多实例负载均衡
- Ribbon调用流程源码解析
- Ribbon负载均衡策略源码解析
- Ribbon重试机制与饥饿加载
- Ribbon自定义负载均衡策略
- Feign与OpenFeign
- Feign设计原理源码解析
- Feign请求压缩与超时等配置
- 服务注册与发现
- 白话服务注册与发现
- DiscoveryClient服务发现
- Eureka集群环境构建(linux)
- Eureka集群多网卡环境ip设置
- Eureka集群服务注册与安全认证
- Eureka自我保护与健康检查
- 主流服务注册中心对比(含nacos)
- zookeeper概念及功能简介
- zookeeper-linux集群安装
- zookeeper服务注册与发现
- consul概念及功能介绍
- consul-linux集群安装
- consul服务注册与发现
- 通用-auatator导致401问题
- 分布式配置中心-apollo
- 服务配置中心概念及使用场景
- apollo概念功能简介
- apollo架构详解
- apollo分布式部署之Portal
- apollo分布式部署之环境区分
- apollo项目权限管理实战
- apollo-java客户端基础
- apollo与SpringCloud服务集成
- apollo实例配置热更新
- apollo命名空间与集群
- apollo灰度发布(日志热更新为例)
- SpringCloudConfig配置中心
- config-git配置文件仓库
- config配置中心搭建与测试
- config客户端基础
- config配置安全认证
- config客户端配置刷新
- config配置中心高可用
- BUS消息总线
- bus消息总线简介
- docker安装rabbitMQ
- 基于rabbitMQ的消息总线
- bus实现批量配置刷新
- alibaba-nacos
- nacos介绍与单机部署
- nacos集群部署方式(linux)
- nacos服务注册与发现
- nacos服务注册中心详解
- nacos客户端配置加载
- nacos客户端配置刷新
- nacos服务配置隔离与共享
- nacos配置Beta发布
- 服务熔断降级hystrix
- 服务降级&熔断&限流
- Hystrix集成并实现服务熔断
- Jemter模拟触发服务熔断
- Hystrix服务降级fallback
- Hystrix结合Feign服务降级
- 远程服务调用异常传递的问题
- Hystrix-Feign异常拦截与处理
- Hystrix-DashBoard单服务监控
- Hystrix-dashboard集群监控
- 分布式系统流量卫兵sentinel
- sentinel简介与安装
- 客户端集成与实时监控
- 实战流控规则-QPS限流
- 实战流控规则-线程数限流
- 实战流控规则-关联限流
- 实战流控规则-链路限流
- 实战流控效果-WarmUp
- 实战流控效果-匀速排队
- BlockException处理
- 实战熔断降级-RT
- 实战熔断降级-异常数与比例
- DegradeException处理
- 注解与异常的归纳总结
- Feign降级及异常传递拦截
- 动态规则nacos集中存储
- 热点参数限流
- 系统自适应限流
- 微服务网关-GateWay
- 还有必要学习Zuul么?
- 简介与非阻塞异步IO模型
- GateWay概念与流程
- 新建一个GateWay项目
- 通用Predicate的使用
- 自定义PredicateFactory
- 编码方式构建静态路由
- Filter过滤器介绍与使用
- 自定义过滤器Filter
- 网关请求转发负载均衡
- 结合nacos实现动态路由配置
- 整合Sentinel实现资源限流
- 跨域访问配置
- 网关层面全局异常处理
- 微服务网关安全认证-JWT篇
- Gateway-JWT认证鉴权流程
- 登录认证JWT令牌颁发
- 全局过滤器实现JWT鉴权
- 微服务自身内部的权限管理
- 微服务安全认证-OAuth篇(撰写中)