服务架构发展

单体架构→分布式/集群架构→服务化架构(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就是一种处理网络问题的技术,它可帮助将非业务功能从代码中剥离处理,并解决例如:服务发现、负载均衡、版本控制、蓝绿部署等问题。