【图解】我使用过的 Dubbo 和 Spring Cloud( 二 ) _架构

文章插图
修改之后的架构大概如下：
1、新增了 CAS 服务器作为统一认证，实现多项目的 SSO，保证登录了一个系统之后，其他的系统也处于登录状态；
2、项目A和项目B，每个项目给对方提供一个 rpc- 的包，里面包含所提供的接口，公用的实体类等；
3、项目A和项目B，配置上增加 Dubbo 配置，比如注册地址，序列化协议扥等。一般都是采用 Dubbo 协议，认证到中；
4、调用对方项目的接口时候，只需要注入 rpc- 包中的类，调用其中的方法即可，dubbo会自动在中查找服务注册信息，发送请求，返回结构。
Cloud
现在的公司架构采用的Cloud 微服务架构，平时自己也有学习和研究Cloud 相关的知识，自己对Cloud 的架构认识大概如下图：

文章插图
大概的架构如下：
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 架构，整个系统复杂度大幅度提升了，更多的是为在高并发和大流量下系统可以正常运行。后记