关于服务拆分

[Evilk]

团队语言:PHP

目前业务较多,项目较多,维护起来,成本太高 现在需要把服务拆分,形成一个一个单独的服务 比如,每个项目都有下单逻辑,现在就想把下单逻辑整合成一个服务 最外层有一个类似于 open-api 的东西,client 调用这个 open-api,open-api 再调用内部的服务

大致是这样的一个方向

目前的选择:

1.腾讯的 tars *这个没有去深入了解过,不知道效果和稳定性如何?

2.还是走普通的 http 协议,架构选择:php-fpm or swoole

我们大概评估了下,对于我们公司来说,没有必走 RPC,普通的 http,足够了

原因:

1.量还没有那么大

2.open-api 调用内部服务,都走的内网,如果用 http,应该还是比较快的

只是想把服务拆分出来,维护起来方便一些,这是最重要的一个原因 不一定要用微服务全套的东西,对于我们公司来说,成本太高了,只是想借鉴微服务的一些优点吧

各位老哥,有什么好的建议吗?

[C603H6r18Q1mSP9N]

提醒 php-fpm 高并发下，吃数据库链接！！！

[Evilk]

@shanghai1998 那如果用 swoole,上连接池,是不是会好很多?

[ChevalierLxc]

我觉得是因为你的项目多 导致你维护困难，拆分服务并不是一个很好的解决方法，拆分出几十个服务后，你会发现要做公用包的拆分，服务链路追踪，一系列的微服务的生态，这些都是工作量，更需要人维护。我觉得根本问题还是你们人太少了，项目太多了，做不过来。

[Evilk]

@ChevalierLxc 目前招人不现实,老哥,还有更好的建议吗?

[leopod1995]

主要还是架构问题吧，建议把比较重、通用的逻辑业务拆出来做成内部服务，至于 api-gateway 就没必要做了。

[ben1024]

加深对业务理解才是主要问题，拆分服务只会带来更大的成本

[594duck]

@Evilk 老哥你做的是对的。我给你指条明路，微服务是瞎吹，SOA 就够了。

你的思路是对的，公共服务以中台的形式拆出来。前台都只是业务层。

中台有 CRM ERP 支付 wms dms tms 等等。前面什么多端多营销的让他们在前面自己看。

你的 qps 在多少多估算 3 倍就好了。应为本来一次流量这么拆了可能会发生 3 次。

大部分公司 SOA 做好就够了，微服务，咱正经人不吹逼

[JJstyle]

你们多个项目下的“单”是相同实体吗？是的话可以，不是的话就没必要了

[specita]

应该没到微服务的地步，拆分感觉只会加重你们的负担。重新梳理一下系统边界，把项目模块业务边界整理下，然后做些调整就好了，代价相应也比较小。

[chihiro2014]

确定系统边界这个得明确。
不然拆分出来就很 gg
最主要的还是表设计得到位啊。
不到位拆分出来，就很痛苦了。
推荐看这个视频
https://www.bilibili.com/video/av60528090

[Evilk]

@leopod1995 我描述的,open-api,其实应该叫项目,比如有 A|B|C,A|B|C,都有一些自己的东西,但都不涉及 DB 操作,然后,外部 client 只能访问 A|B|C,A|B|C 再通过内网,访问内部服务

[Evilk]

@ben1024 老哥,可以更具体点吗?目前业务理解是到位的,只是因为历史原因,很多项目,有很多重复的部分,现在就是要把这些重复的提取出来而已,方便维护

[Evilk]

@594duck 是的,因为我们用不上微服务全套,只是借助微服务一些优点而已,方便维护,仅此而已🤝

[Evilk]

@JJstyle 是相同实体

[Evilk]

@specita 不是很理解你说的"模块业务边界",还请教?

[ben1024]

@Evilk
1.建议先内部抽取服务层，当前已经是项目多维护成本高，在进行拆分服务维护成本会增加
2.做服务整合要考虑事务一致性，针对下拉单服务是否能单独存在跟其他服务没有依赖，在最后的步骤进行拆取，后面迭代会遇到拆取后的服务越来越大

[zencoding]

你需要的是 SOA

[C603H6r18Q1mSP9N]

上连接池还是一般般，反正测试下来 java 是 swoole 的 2 倍

[dvaknheo]

首先从拆分数据库开始

[MaxFang]

也遇到相同的问题，感觉主要还是梳理业务逻辑，划清系统模块边界和职责。