1. 微服务系统架构演变

单体应用架构 -> 垂直应用架构 -> 分布式架构 -> SOA 架构 -> 微服务架构。

?

（1）单体应用架构 - all in one。

优点：架构简单、开发成本低，项目部署在一个节点上，维护方便。

缺点：全部功能集中在一个工程中，不易于开发维护；模块间紧密耦合单点容错率低；无法针对不同模块有针对性的优化、水平扩展/负载均衡（水平扩展：某一服务压力特别大，从而进行增设复本）。

场景：学校里自己玩、20年前的玩法。

（2）垂直应用架构

优点：系统实现了流量的分担，解决了并发问题，可以针对不同模块进行优化和水平扩展；系统间隔离，提高了容错率。

缺点：系统间独立，无法进行相互调用，会有重复的开发任务。

场景：传统行业。OA 、银行财务系统...

（3）分布式架构

优点：将公共模块抽取成一个个公共的服务。抽取公共的功能为服务层，提高代码复用性。

缺点：系统间耦合度变高，需要进行远程服务调用了，调用关系错综复杂，难以维护。

场景：适用于刚起步的公司。为微服务架构进行演变。

问题：分布式架构庞大后引发的问题：分布式缓存（可以用Redis解决），分布式锁（可以用Redis或Zookeeper解决），分布式Session（可以用Redis解决），分布式事务...

（4）SOA

????????解决了分布式架构中水平扩展中出现的服务副本掉线的问题，如果采用轮询机制的话，副本掉线后会出问题，此时引入ESB。

优点：ESB(企业服务总线 Enterprise Service Bus)，解决服务间自动调用的关系。可以进行协议转换、协调整个服务。

缺点：服务间会有依赖关系，某一环节出错可能造成服务雪崩/宕机（服务雪崩：在扇出调用时可能出现的问题）；各个服务间强耦合(中心化明显)，所有服务都放在bus中，服务间关系复杂，运维部署困难，不易扩展。

也可以用Dubbo来完成去中心化。

（5）微服务架构Spring Cloud

????????将服务以更细粒度的“彻底拆分”（商品服务->普通商品服务、秒杀商品服务...），针对每个服务，可以有更加细化的解决方案。

? ? ? ? 微服务架构比SOA 架构拆分力度更细，微服务架构都需要独立部署；SOA架构数据库存储共享，微服务架构都是单独的数据库以保证每个服务之间不共享；

优点：去中心化，中心（网关、注册中心）。服务间原子化拆分，独立打包易于扩展，微服务之间采用Result等轻量级http协议相互调用。

缺点：技术成本、硬件成本、开发成本高；各位服务间独立部署，在模块调用时分布式会变得麻烦（分布式锁、分布式缓存...）

场景：拆分粒度根据业务复杂度来定。

2.?Spring Cloud Alibaba 组

Spring Cloud Alibaba 包含了多种开发分布式微服务系统的必需组件?： 可以通过 k8s+Docker --> 实现快速部署。

通过 Spring Cloud Alibaba 的这些组件，我们只需要添加一些注解和少量配置，就可以将 Spring Cloud 应用接入阿里微服务解决方案，通过阿里中间件来迅速搭建分布式应用系统。

组件名称解决问题功能实现Nacos这么多小服务，如何管理他们？配置管理和服务管理平台feign这么多小服务，他们之间如何通信的？应用于服务之间的远程调用gateway这么多小服务，客户端怎么控制他们？网关去对应到路由到服务中，可以实现认证、授权、限流等问题Sentinel这么多小服务，出现了问题如何自处理？把流量作为切入点,从流量控制,熔断降级,系统负载保护等多个维度保护服务的稳定性。RocketMQ如何承接熔断降级之后的数据堆积问题？承接熔断降级后数据堆积问题，把堆积的数据放在RocketMQ中。Seata如何解决数据入库时的分布式事务一致性问题？高性能微服务分布式事务解决方案。DubboJava RPC 框架Alibaba Cloud OSS阿里云的云存储服务Alibaba Cloud Schedulerx分布式调度产品,支持周期性的任务与固定时间点触发任务

---

1.本站遵循行业规范，任何转载的稿件都会明确标注作者和来源；2.本站的原创文章，会注明原创字样,如未注明都非原创，如有侵权请联系删除！；3.作者投稿可能会经我们编辑修改或补充；4.本站不提供任何储存功能只提供收集或者投稿人的网盘链接。