微服务业务拆分的问题

[开拓者Amadues]

举个例子，不知道理解得对不对。

比如公司有ABC三个项目组，每个组负责一块业务，那么ABC整体是不是可以认为是微服务模式的？

每个组自己内部还有没有必要继续做微服务来拆分业务？

[韩_师兄]

微服务,就是一个服务只做一件事,按照你的说法. 如果你们A项目组, 只处理一种类型的业务,那就不用再分了

[老王就是我]

@开拓者Amadues 依然是ABC服务，如果公司的要求是，支付项目必须完全独立，对外只提供api，那么B组就不能参与进入公司微服务中，而应该自己独立组成一个服务

[老王就是我]

@开拓者Amadues 第一种例子，不是微服务。第二种，是。所以我才说具体看业务是否有关联性，关联性的强弱

[开拓者Amadues]

@老王就是我 你后面那个例子里，B和C是两个小组分别负责某块业务，本身是不是已经是微服务了？

[老王就是我]

微服务，是根据业务来计算的。微服务解决的问题是分布式的容错性，即单点故障不会影响整体运行，也就是说，某个服务器挂了其他服务能正常运行。

而无论公司有多少个项目组，只要它们的业务不属于同一个大框架内，微服务就不是必须的。

举个例子：A项目组搞企业内部资产管理，B项目组搞互联网移动支付，C项目组搞商城。它们都不是强关联的，A项目的资产管理是近似完全独立的项目组，B的支付和C的商城有关联性，但两者也不是相互依存的，B和C也可以互相独立。那么ABC就不是必须搞微服务。

但如果换一种🌰

A不变，B是C的其中一个模块，那么，B和C就适合做成微服务，因为B依附于C，C不可独立存在。

所以，分不分微服务，主要看业务大小和独立度

[=PNZ=BeijingL]

微服务针对的是业务，不是小组，小组负责的也可能是一个微服务聚合

[li905663280]

微服务是一个项目内，安装大的业务功能模块进行细分为多个子服务，每个服务单独运行访问单独的数据库或者表。服务与服务之前通过注册与发现进行调用。外层系统访问统一通过网关进行访问。