拆分

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

基础设施

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