![【图解】我使用过的 Dubbo 和 Spring Cloud](http://img.gansulong.com/231024/1P3225424-2.png)
文章插图
修改之后的架构大概如下:
1、新增了 CAS 服务器作为统一认证,实现多项目的 SSO,保证登录了一个系统之后,其他的系统也处于登录状态;
2、项目A和项目B,每个项目给对方提供一个 rpc- 的包,里面包含所提供的接口,公用的实体类等;
3、项目A和项目B,配置上增加 Dubbo 配置,比如注册地址,序列化协议扥等。一般都是采用 Dubbo 协议,认证到中;
4、调用对方项目的接口时候,只需要注入 rpc- 包中的类,调用其中的方法即可,dubbo会自动在中查找服务注册信息,发送请求,返回结构 。
Cloud
现在的公司架构采用的Cloud 微服务架构,平时自己也有学习和研究Cloud 相关的知识,自己对Cloud 的架构认识大概如下图:
![【图解】我使用过的 Dubbo 和 Spring Cloud](http://img.gansulong.com/231024/1P3221551-3.png)
文章插图
大概的架构如下:
1、用户访问Nginx,跳转到前台页面;
2、当页面有ajax请求时候,通过访问nginx,nginx转发到Cloud,然后根据路由规则转发到具体的某个微服务中;
3、nacos作为服务注册发现 + 动态配置 + 服务监控使用,这里替代了++ admin,其中 项目,没有可视化页面,同时必须配合Cloud Bus + 通过订阅消息才可以实现配置的动态刷新 。是nacos一个项目融合了多个功能,如果以集群方式部署,大大节省了项目的数量,比如++ admin 都要实现高可用,那么需要至少 3*3个实例,而 nacos 只需要3个实例即可,同时降低项目复杂度 。同时动态配置这块nacos提供了可视化界面,并且有配置信息回滚等操作,简单且功能强大 ;
4、每个微服务之间难免有服务的调用,比如支付服务在付款的时候,必须调用订单服务,把订单中商品的数量和价格等信息查询过来,这里使用的是 Feign,每个微服务本身属于服务,给调用方提供一个的sdk,当调用方使用中的方法时候,就是实现了微服务之间的 Fegin 调用,同时配有熔断功能,防止接口长时间不返回,阻塞后续请求造成服务的连锁奔溃反应 。同时还包括有的负载均衡和自动重试功能,某个服务无法访问时候,自动进行切换并重试;
5、一次请求,可能涉及多个微服务,如果请求超时,那么必须要能定位到哪一步的请求耗时过多,方便后续的优化修改,这时候就必须使用微服务的全链路追踪,这里使用了,是因为是通过字节码增强技术实现,无须手动埋点,切性能较高 。+的组合,需要多个项目,同时是通过 http 请求收集信息,性能较差;
6、其他的分布式事务、分布式主键发号器、分库分表、缓存等方案就暂时不写,主要就是为了表达下Cloud 架构下的 Java 项目结构 。
总结
大部分情况下,说区别其实是个伪概念,因为 Dubbo 能实现的方式Cloud 也能实现,反之亦然 。下面所说的区别是针对我个人曾经经历过的项目,个人所得出的感觉,欢迎不同观点朋友的探讨:
Cloud 项目结构: 微服务化,每个服务关于某个具体领域,每个项目拥有自己的数据库 。采用前后分离技术,前台页面关注于效果展示,页面统一访问网关,由网关根据路由规则转发到具体的某个微服务中;项目定位:每个项目称之为微服务,只提供 http () 接口,不负责页面;研发团队:以微服务领域划分,每个微服务应该有自己的团队,独立开发和维护,每个团队尽可能将自己所负责的项目做到做好;使用群体:以广大用户为主,人数成千上万乃至亿;性能要求:一般微服务项目要求全年3个9(99.999%)或者4个9(99.9999%)高可用,微服务需要具备自动降级、故障切换、熔断、在线扩容、重启等功能;技术聚焦:采用Cloud 架构,整个系统复杂度大幅度提升了,更多的是为在高并发和大流量下系统可以正常运行 。后记
- 立木为信的意思 立木为信的意思简单5字
- 明日见的种植技巧和管理方法
- 关于未婚妻 湖南卫视的介绍 未婚妻 湖南卫视
- 春季菠菜的种植关键点
- 关于360儿童安全手环的介绍 360儿童安全手环
- 有幸识你繁体字怎么写
- 狱是怎么演变来的
- 电影保你平安适合孩子看吗
- 我的快手为什么不显示竞猜
- 一个电子工程师对电子业现状的感慨--新手慎入【转帖】