微服务架构发展及趋势
本文内容:简要说明服务架构演变过程及特点,以及微服务架构未来发展趋势
服务架构发展
单体架构→分布式/集群架构→服务化架构(SOA面向服务)→微服务架构
单体机构
单体服务:系统维护困难、出现故障时会导致整个系统不可用
分布式集群架构
分布式集群架构:是将服务进行垂直拆分、水平拆分垂直拆分
:根据业务等进行拆分,一个电商系统可以分为:用户系统、订单系统、商品系统等多个子系统的组合水平拆分
:将一个服务进行扩容,通过负载进行调度。将一个用户系统扩容成3个,分别部署在不同的机器上,通过负载均衡策略将请求分发到不同的用户系统服务器上。
服务化架构(SOA)
我们发现用户系统、订单系统、商品系统等,都会用的权限认证、用户信息查询等相同的功能,每个系统都维护一份自己用户管理代码,一是代码重复无,二是系统间信息隔离,数据不共享。
那么,将共性的部分提起出来做为一个服务供所有系统使用,每个系统不再各自实现,也就形成了面向服务架构(SOA)
面向服务架构(SOA)帮我们解决:代码复用、信息孤岛、数据互通等问题
微服务架构
微服务本身也算是面向服务架构(SOA),它是SOA发展道路上的优化选择,关注的是服务拆分力度,即:如何将服务合理的拆的更细、更小
,具体维度要根据业务、资金、人员等因素,来定界一个服务功能的大小。
PS:微服务也是分布式架构,它是分布式架构发展下的最优产物。
分布式关注的是服务分开部署,也就是如何将单一服务部署,变为多服务部署(垂直+水平拆分)。
微服务关注的是服务拆分力度,即:一个服务要拆分到多大的维度合适
随着业务量的增加,服务规模也越来越大,我们的服务器也由原来的的几台、十几台,变成现在的成百上千台,相应的也出现了一些新的问题,例如:
- 底层系统资源问题
- 服务间通信问题
- 服务治理问题
- 服务运维问题
为了解决这些问题,衍生出了新的技术框架,比如: - 使用SpringCloud、Dubbo等微服务框架,解决软件开发层面的问题。
- 使用Docker、K8S等,解决微服务软运维问题
微服务早期由于技术原因,人们关注的重点都是软件开发层面的问题,近几年随着容器化管理技术Docker、容器编排技术Kubernetes等,运维层面技术的成熟和推广,微服务体系由原来的注重开发,逐渐演变为
设计、开发、运维一体化的DevOps管理模式
。
服务网格架构时代?
通过服务架构的发展历程,我们可以看出:微服务实现了服务间的解耦,但同时也引发了很多非业务问题。 比如:服务发现、服务限流、服务监控、服务权限控制、服务版本控制等。
Spring Cloud等微服务框架,虽然为我们提供了,例如:解决服务发现问题的注册中心Eurek
、解决限流问题的断路器Hystrix
,以及解决服务调用问题的Ribbon、Fegin
等技术,但是我们看看是它如何使用的?导入dependency依赖,将将它们和我们的业务代码一起打包部署,也就是说·Spring Cloud是一种”侵入式”解决方式
,它虽然简化了我们处理非业务问题的难度,但是开发人员还是需要对这部分功能一定了解。
那么,是否可以让业务开发人员,只关心业务代码开发,而不必将精力耗费在非业务代码的开发上?
Service Mesh就是一种处理网络问题的技术,它可帮助将非业务功能从代码中剥离处理,并解决例如:服务发现、负载均衡、版本控制、蓝绿部署等问题。
微服务未来发展趋势,将是集:DDD领域驱动设计+ Spring Boot/Cloud/Dubbo微服务框架 + Docker容器管理+K8S容积编排 +Service Mesh服务网格+ …等技术协同配合的发展趋势
本文地址:https://blog.csdn.net/HRebel/article/details/107448930
上一篇: Vue 项目性能优化 —实战—面试
下一篇: DBeaver操作数据表的拷贝的实现