Dubbo,SpringCloud,ServiceMesh

微服务

微服务（Microservices）是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

微服务的优点：

1.降低复杂度

将原来偶合在一起的复杂业务拆分为单个服务，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能。

2.可独立部署

由于微服务具备独立的运行进程，所以每个微服务可以独立部署。当业务迭代时只需要发布相关服务的迭代即可，降低了测试的工作量同时也降低了服务发布的风险。

3.容错

在微服务架构下，当某一组件发生故障时，故障会被隔离在单个服务中。 通过限流、熔断等方式降低错误导致的危害，保障核心业务正常运行。

4.扩展

单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。

 

微服务的缺点：

1.团队沟通的过载

微服务架构降低了团队管理的难度，但是确不能降低团队沟通的需求。

2、正式文档的过载

每一个独立的运行部件需要持续维护其规格和接口文档，这些文档是其它团队使用这些部件的必要条件。

3、不一致性

我们可以为每一个组件选择不同的技术栈。这导致了不一致的应用设计和架构，而这会在更长期的运维期间增加系统维护成本。

4、DevOps的复杂度

我们需要拥有一支成熟的DevOps团队去处理微服务架构的应用的复杂性。

5、资源使用

运行这些微服务架构的应用的初始投资会比较大。

6、网络通信开销

分布式系统的产生的网络开销比单机应用多很多。需要更加可靠和快速的网络连接。

7、编码和解码

这个容易理解，也会产生性能问题。

8、网络安全

通过网络进行通信的系统更容易产生安全缺陷。

9、测试

测试微服务架构的应用绝对比单体应用难很多。

10、产品监控

监控微服务架构应用的成本会更高，很难获得合适的工具，需自研。

 

Dubbo

Dubbo 是一个分布式服务框架，致力于提供高性能和透明化的 RPC 远程服务调用方案，以及 SOA 服务治理方案。简单的说，Dubbo 就是个服务框架，说白了就是个远程服务调用的分布式框架。

模块注解：

Provider: 暴露服务的服务提供方。

Consumer: 调用远程服务的服务消费方。

Registry: 服务注册与发现的注册中心。

Monitor: 统计服务的调用次调和调用时间的监控中心。

Container: 服务运行容器。

流程详解：

0.服务容器负责启动，加载，运行服务提供者（Standalone 容器）。

1.服务提供者在启动时，向注册中心注册自己提供的服务（Zookeeper/Redis）。

2.服务消费者在启动时，向注册中心订阅自己所需的服务。

3.注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

4.服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

5.服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心（根据数据可以动态调整权重）。

 

Dubbo优点

1.Dubbo 支持 RPC 调用，服务之间的调用性能会很好。

2.支持多种序列化协议，如 Hessian、HTTP、WebService。

3.Dobbo Admin后台管理功能强大，提供了路由规则、动态配置、访问控制、权重调节、均衡负载等功能。

4.在国内影响力比较大，中文社区文档较为全面。

5.阿里最近重启维护。

 

Dubbo问题

1.注册中心严重依赖第三方组件（zookeeper 或者 redis），当这些组件出现问题时，服务调用很快就会中断。

2.Dubbo 只支持 RPC 调用。使得服务提供方（抽象接口）与调用方在代码上产生了强依赖，