技术干货分享：微服务浅谈服务治理的演变过程

上面提到了，dubbo还存在一些问题 ，其实dubbo存在的问题 就是 微服务要解决的问题，这里 再总结一下。当然，dubbo和微服务的侧重点不一样，dubbo侧重于内部接口之间的RPC，而微服务则侧重于对外提供服务。

• 统一入口
• 安全控制：防刷限流
• 统一鉴权：应用鉴权、用户鉴权、OAuth鉴权、ACL
• 协议转换：http、dubbo、Protobuf
• API配置管理
• API上线、下线
• API与服务接口映射
• 监控与报警
• 整体架构的可拓展、高并发、分布式
• 服务容器自动收缩、扩容

实现方案

• 负载均衡层：nginx/lvs/F5
• 微服务层

高性能服务网关;

统一入口、API配置管理、分流鉴权、服务监控、协议转换;

API映射、OAuth2.0、API文档管理;

分布式、可拓展;

• 服务治理层

成熟的服务治理框架dubbo;

MQ服务之间解耦;

• 弹性云

服务docker化;

基于访问压力的实时集群调度与管理;

弹性云

这里简单介绍一下弹性云的概念，微服务要想提供好服务，保证API不能挂掉并且有好的性能，需要很高的运维要求。这里的弹性云便是自动化运维解决方案，对访问压力进行监控，根据监控解决调度应用的发布和回收。

服务网格(Service Mesh)

2017 年底，非侵入式的 Service Mesh 技术从萌芽到走向了成熟。

Service Mesh 又译作“服务网格”，作为 服务间通信的基础设施层 。

如果用一句话来解释什么是 Service Mesh，可以将它比作是 应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控 。对于编写应用程序来说一般无须关心 TCP/IP 这一层(比如通过 HTTP 协议的 RESTful 应用)，同样使用 Service Mesh 也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情，比如 Spring Cloud、OSS，现在只要交给 Service Mesh 就可以了。

Service Mesh 的来龙去脉：

1. 从最原始的主机之间直接使用网线相连
2. 网络层的出现
3. 集成到应用程序内部的控制流
4. 分解到应用程序外部的控制流
5. 应用程序的中集成服务发现和断路器
6. 出现了专门用于服务发现和断路器的软件包/库，如 Twitter 的 Finagle 和 Facebook 的 Proxygen，这时候还是集成在应用程序内部
7. 出现了专门用于服务发现和断路器的开源软件，如 Netflix OSS、Airbnb 的 synapse 和 nerve
8. 最后作为微服务的中间层 Service Mesh 出现

Service Mesh 有如下几个特点：

• 应用程序间通讯的中间层
• 轻量级网络代理
• 应用程序无感知
• 解耦应用程序的重试/超时、监控、追踪和服务发现

Service Mesh 架构图：

关于微服务和服务网格的区别，我的一些理解： 微服务更像是一个服务之间的生态，专注于服务治理等方面，而服务网格更专注于服务之间的通信，以及和 DevOps 更好的结合 。

（编辑：源码网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!