SpringCloud微服务拆分原则

服务拆分原则服务拆分一定要考虑几个问题什么时候拆如何拆什么时候拆一般情况下对于一个初创的项目首先要做的是验证项目的可行性。因此这一阶段的首要任务是敏捷开发快速产出生产可用的产品投入市场做验证。为了达成这一目的该阶段项目架构往往会比较简单很多情况下会直接采用单体架构这样开发成本比较低可以快速产出结果一旦发现项目不符合市场损失较小。如果这一阶段采用复杂的微服务架构投入大量的人力和时间成本用于架构设计最终发现产品不符合市场需求等于全部做了无用功。所以对于大多数小型项目来说一般是先采用单体架构随着用户规模扩大、业务复杂后再逐渐拆分为微服务架构。这样初期成本会比较低可以快速试错。但是这么做的问题就在于后期做服务拆分时可能会遇到很多代码耦合带来的问题拆分比较困难前易后难。而对于一些大型项目在立项之初目的就很明确为了长远考虑在架构设计时就直接选择微服务架构。虽然前期投入较多但后期就少了拆分服务的烦恼前难后易。怎么拆微服务拆分时粒度要小这其实是拆分的目标。具体可以从两个角度来分析高内聚每个微服务的职责要尽量单一包含的业务相互关联度高、完整度高。低耦合每个微服务的功能要相对独立尽量减少对其它微服务的依赖或者依赖接口的稳定性要强。高内聚首先是单一职责但不能说一个微服务就一个接口而是要保证微服务内部业务的完整性为前提。目标是当我们要修改某个业务时最好就只修改当前微服务这样变更的成本更低。一旦微服务做到了高内聚那么服务之间的耦合度自然就降低了。当然微服务之间不可避免的会有或多或少的业务交互比如下单时需要查询商品数据。这个时候我们不能在订单服务直接查询商品数据库否则就导致了数据耦合。而应该由商品服务对应暴露接口并且一定要保证微服务对外接口的稳定性即尽量保证接口外观不变。虽然出现了服务间调用但此时无论你如何在商品服务做内部修改都不会影响到订单微服务服务间的耦合度就降低了。明确了拆分目标接下来就是拆分方式了。我们在做服务拆分时一般有两种方式纵向拆分横向拆分所谓纵向拆分就是按照项目的功能模块来拆分。例如商城项目中就有用户管理功能、订单管理功能、购物车功能、商品管理功能、支付功能等。那么按照功能模块将他们拆分为一个个服务就属于纵向拆分。这种拆分模式可以尽可能提高服务的内聚性。而横向拆分是看各个功能模块之间有没有公共的业务部分如果有将其抽取出来作为通用服务。例如用户登录是需要发送消息通知记录风控数据下单时也要发送短信记录风控数据。因此消息发送、风控数据记录就是通用的业务功能因此可以将他们分别抽取为公共服务消息中心服务、风控管理服务。这样可以提高业务的复用性避免重复开发。同时通用业务一般接口稳定性较强也不会使服务之间过分耦合。