1. 理解需求；首先，你需要深入了解项目的【需求和业务场景】。这个阶段更多的就是拆解和评审需求。
2. 体量规模；在做设计之前，先了解此微服务架构要承载的【业务量】，这势必会影响到架构的设计和技术的选型。
3. 小规模类：
   1. 尽可能减少技术栈的过多使用，也不要自建，市面上越稳定，越轻量运维的，越优先考虑。
   2. 系统不要过多的拆分，保证最核心的也模块支撑即可。
4. 中大规模
   1. 按照不同的职责边界和共性通用功能，以及遵守软件设计原则的康威定律描述，按照抽象、分治和知识(设计原则、设计模式、DDD)可以进行合理拆分；
   2. 通常可以把不同边界，有业务语义链路流程的服务，拆分成底层支撑模块，也就是一个独立的功能领域，拆分后在基于这些领域服务模块，串联所需要的业务流程。那么在系统架构分层中，贴近对外提供服务的功能串联提供API这一层的生命周期较短，可能会随着业务的调整不断的演变，但通过这样的拆分后，底层支撑的领域服务，其实就不会被污染了，也能达到共用的目的。
   3. 一些无业务流程，单纯的组件设计，把一些服务中通用共性的功能，提炼出来开发成 SpringBoot Sarter 例如；路由、切量、熔断、日志、映射、其他组件包装等类型的功能，开发成组件来维护。这样所有有需要的系统都可以引入使用了。
   4. 举例说明：例如把一套电商服务，拆分为；用户系统、账户系统、商品系统、交易系统、结算系统、清分系统、台账系统、物流系统、客户系统、运营系统、商家系统、营销系统(再拆；券中心、活动系统、抽奖系统、灌卷系统)、客服系统、履约系统等等，这些拆分后的服务组合出一整套电商平台。
   5. 收集不同功能的开源组件，选出市面上使用比较广泛并且稳定的组件；
5. 项目启动；架构评审、设计评审、工期评估、风险评估、人员评估、联调时间等。
6. 上线计划；上线时间、服务申请、权限开通、系统监控等。

贡献者

codingLab

版权所有

版权归属：codingLab

许可证：bugcode