拆分

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

基础设施

上面划分为 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，对系统消耗较小