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