写点什么

模块六

作者:Only
  • 2022 年 1 月 28 日
  • 本文字数:653 字

    阅读完需:约 2 分钟

拆分

微服务划分:按照业务边界划分,主要还是参考业内成熟的电商模式。业务刚开始,变化比较多,也就没有足够的依据按照质量属性来拆分,可以根据公司后期业务迭代情况,再根据业务来细分。



基础设施


上面划分为 7 个微服务。虽然要遵循 3 个火枪手原则,但是前期阶段,部分服务的开发工作量会过多,如果再拆分,人手会短缺。所以,多出来的 4 个人中,一个分配到商品服务,另外一个分配到交易中。

最后剩余两人(一个应该要是技术经理,另外一个需要技术广度和一定的深度),来做基础设施的维护和部分定制化开发。


微服务框架: Dubbo。Dubbo 相对 Spring Cloud,前期投入成本相对较低。因为 Spring Cloud 因为是插拔式的,所以配置会较多,并且版本之间的兼容会是个较大的问题,相同服务治理的功能,Spring Cloud 依赖更多,对初创团队成本较高。


服务注册发现:Nacos,因为 Nacos 同时支持配置中心,Dubbo 天然集成。

路由,容错:Dubbo 自身提供,只需配置即可

流控,降级:Dubbo 自身提供

服务安全:Dubbo group 也可实现

网关:前期选择 Nginx

日志中心:Loki,日志服务不选择 ELK,相对来说,ELK 过重。并且后续需要使用 grafana 来作为整个系统的监控面板

分布式锁:因为本身要用 redis 作为缓存,所以选择使用 redis 的能力来提供分布式锁的校验功能。如果选择 zookeeper 来作为分布式锁来支撑,代价较高,并且 zk 的 TPS 远远小于 redis

消息队列:RocketMQ。相比较 kafka,RocketMQ 的吞吐量差不了多少,并且 RocketMQ 支持延迟队列和事务消息,所以选择使用 RocketMQ

服务监控和跟踪:SkyWalking。和 Dubbo 集成较好,并且相对 Pinpoint,对系统消耗较小

发布于: 刚刚阅读数: 2
用户头像

Only

关注

还未添加个人签名 2020.05.27 加入

还未添加个人简介

评论

发布
暂无评论
模块六