Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

不要勉强服务化

  把复杂的系统服务化是一种优化手段,但很多人却是在为了服务化而服务化,那完全是在捣乱。服务化是一件很累的事情,应该是为了达成某些目的才有必要服务化,比如提高系统稳定性、节省硬件资源、梳理逻辑之类的。脱离了目的的服务化都是耍流氓,那只会把系统搞得更糟。
  如果服务之间是强依赖的,那么对于业务而言,它的风险就是所有强依赖的服务的风险总和。由于每个服务是单独部署的,每个服务本身的风险除了自己的代码问题外,还有非代码风险,比如部署风险、网络风险等。这类代码外的风险并不会因服务拆分而拆分出去。假如我们原来有一个 A 服务,它的代码风险为 1,非代码风险也为 1。现在把它拆成两个服务 A1 和 A2,于是 A1 和 A2 的代码风险分别为 0.5,因为拆分后代码量小了,代码逻辑简化了。但是非代码风险依然是分别都是 1。所以这时候服务拆分后不仅情况不会变好,还会让原来只有 2 的风险变到 3,增加了 50%。
  其实每个项目的代码风险和非代码风险是不同的,并不全是 1:1 的比例。有些项目部署上非常困难,而且难以监控,它的部署风险就比代码风险高。而有些项目可能是部署相对稳定,但是业务逻辑非常复杂,那么它的代码风险就比部署风险高。所以服务拆分的时候应该考虑好怎么分才可以避免风险,并不是一股脑地就细分。偶尔可能还要把一些部署风险高的服务合并到一起来避免风险。
  服务拆分以后还会遇到一些跨机房调用的问题,这是个大坑。如果是同机房局域网调用,那性能影响确实可以小到忽略。但如果跨机房,甚至走了外网。即便服务的代码没问题,服务部署也没问题,网络层面的问题又会成为一个瓶颈。反正我觉得外网是最不可靠的,一架挖掘机都能把你搞挂。
  我的建议是,如果没有特别显著的优势,没必要浪费时间去做服务化。有时候耦合成一坨屎的服务可能也比一堆精美的服务依赖要稳定。
网名:
54.162.218.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^