服务架构发展
单体架构→分布式/集群架构→服务化架构（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
