dubbo微服务总结

 整个微服务系统 架构图

 

接入层： 动静分离，反向代理，分发，负载  等

可以 使用 OpenResty ，  OpenResty 也可以做 防火墙

 

文件系统： 分布式文件系统

 

应用层 dubbo微服务 架构例图

 

 

dubbo 常识

 

看看 dubbo 架构图 ：  http://dubbo.apache.org/zh-cn/docs/dev/design.html

dubbo 依赖于 反射和代理 去实现的， 

dubbo 消费方服务是   不停监听 注册中心的 注册服务的， 如果服务数据改变，将 注册的服务 数据 从注册中心 给 拿到 消费者服务里面。

大致 了解dubbo 的流程

 

将 dubbo 基本架构图，熟悉或者背下来

 

Registry 不是只能用 zookeeper， 可以使用 redis 或者其他 的

 

 

服务治理

1， 服务治理是一个 从SOA时代就诞生的大的概念

以书架说明：

进了 新书，要知道 书放在哪里， 上一本新书，要通知别人来一个新书在哪个架子上，这样别人就可以去找： 服务注册和服务发现

书没有了，不见了，要告诉别人： 服务熔断与服务降级

如果书架越来越多，书籍很多，都成一个图书馆了，就需要人维护了： 服务运维，部署，监控

除了业务不见服务治理，其他方面都可以说是服务治理

 

2. 服务治理贯穿于微服务体系的整个生命周期

3， 服务治理包括但不限于服务注册，服务发现， 服务监控等

4. 理解服务总线的概念

就是负责服务 整个生命周期的。 SOA的服务总线就是太重了。

 

服务网关

dubbo 不能接入 HTTP ，是一个 二进制的传输。

用dubbo 可以用 springmvc 做服务网关

 

分布式事务

分布式事务强调的不是事务，解决是 事务的单点。保证数据最终一致性。

TCC 效率比较高， 而基于 消息事务会有消息是挂起或者是有资源的销耗，性能比较差，响应可能比较慢

TCC 关键是 TRY 阶段，预留资源（比如用乐观锁占着资源）

 

服务幂等性

分布式事务要解决 幂等性

比如dubbo 默认重试 3次

分布式锁： 基于乐观锁 ， 可以解决多服务之间冲突的问题

也就是 支付服务 处理的时候， 如果发现 标识已经被锁住了，就不处理了，因为已经有其他服务做了，如果没有锁就 进行处理，并上锁。

 

服务设计要尽量无状态， 服务设计要考虑幂性。

比如 订单和支付 放在一个 服务里面，就不用管分布式事务了。

 

限流方案

 

 

因为令牌桶允许 有请求的峰值，所以一般都是用令牌桶

 

自动化运维与部署

 

docker 要会的， falcon 是小米开源的 监控工具

 

在Linux 里面启动 微服务 ， 后台 启动 命令 比如 ： nohup java -jar xx.jar &

 

可以使用 OpenResty  ： 通过 Lua 扩展 NGINX 实现的可伸缩的 Web 平台

做 网关，或者请求入口，类似NGINX的 作用 

http://openresty.org/cn/

 

 

最终

微服务不要过度设计，要结合业务

 

 

 

 

转载于:https://my.oschina.net/ouminzy/blog/3083366