用户工具

站点工具


about_soa

服务化,你真的需要吗?

今天又到了思考人生的时间,人的一生很是短暂,但是我们还是要弄明白我从哪里来,现在在哪里,要到哪里去?反过来讲,我们平时做事情,解决问题也是一样的,我们做了什么事情,现在遇到了什么样的问题,未来将要如何应对呢?

下面进入正题,现在很多大大小小的公司在技术上都会面临要不要服务化的伪命题,抛开成见,我来讲讲我的看法。一般面临这个问题的公司场景大致有以下几种: 公司发展状态太快,一群人围着修改一个工程,效率低下,还容易出问题,而且未来业务更为复杂,如果不进行底层服务的抽象,大家就没法玩了,这时候就想拆分代码了。 某领导听说现在业界都使用了高大上的服务化技术,比如BAT这样的公司,我们做为一家传统的大企业,怎么能输给互联网的杂牌军呢,所以我们也要搞SOA架构。 团队前期发展太快,但是技术积累有限,导致发展一定阶段遇到瓶颈代码太混乱了,这时候恰好来了个所谓的高大上的架构师,忽悠说,服务化吧。

业务停滞不前,技术团队实在没事可做,为了证明我们的存在,好歹搞点什么吧,那就把看似通用的一些代码服务化吧。

我想了下,以上的四点大致归纳了服务化的原因,如果还有其他,请补充。。。

然后我们一点一点来看,关于第一点,大家一看就觉得服务化很有必要,只是如何做的问题,这个我们后面来说。先看后面三点。

第二条,我觉得纯粹是装B被雷P了,苦了程序员,害了老板,为了服务化,加班加点拆分代码,结果改了之后系统之间互相调用发生什么都不知道,平时开发项目启动都启动不了了。。。咋整啊?更可恨的是某些技术人员或者所谓的架构师为了证明自己多么牛逼,还怂恿领导。。。服务化,你真的需要吗?你真的有能力维护周边的衍生产品吗?

第三条,这种场景未必不适合服务化,但是还是要具体问题具体分析,很多所谓高大上的架构师,都想只谈技术,不谈业务,不去看代码,就意淫你的系统架构,有人说,不研究业务的架构师就是耍流氓,所以,请大家小心。

关于第四条,就仁者见仁,智者见智了,假如真的没事情做了,技术上做些储备,把架构优化的更好,为未来冲量做准备,未必不是一件坏事情。人活着总得有些盼头吧。。。

接着我们来看看如何做服务化,我觉得就跟人一样,饭要一口一口吃,一步到位的架构是很难在快速发展的组织中实行的,因为业务不可能停止不前,所以,我的方案是: 根据组织结构快速的把代码剥离,远程部署。 等稳定之后,每个模块组织业务专家进行领域建模 等基础服务稳定之后,考虑后续的服务治理 要注意的是,架构不可能一部到位,后2点是需要长期面临和规划的问题,能稳定1年的架构方案,那已经是不错了,持续集成和重构不仅是架构的问题,也牵涉到了管理的艺术。

最后,我们来看服务化常见的一些问题:

要不要用ESB? 答:esb只是一种服务化的工具而已,要结合你的场景来看是否合适,服务化的关键是在于对业务模型的梳理和抽象,对整个系统分而治之,专人维护,不是一个工具就可以解决你的问题的。另外esb提供的业务编排能力是否是你目前面临的问题呢?

​2.服务化之后,是不是开发就很简单了?

答:服务化和开发效率的提升其实是两码事,如果工程组织的不合理,配置又混乱,反而导致开发人员更加效率低下,甚至日常开发都遇到苦难,毕竟依赖的服务有可能是其他部门提供的,没有MOCK环境,日常多头痛?

3.我要选择哪种服务化的框架呢?

答:目前互联网公司的主流服务化框架都是轻量级的,客户端都是直接请求服务的提供者,服务化框架提供了封装的客户端,以及统一的服务注册中心。至于服务调用的协议,基于二进制的hessian等都是比较常见的。

4.为了服务化我现在招聘了一名架构师,是不是交给他就可以完成所有工作? 答:对不起,如果架构师不了解业务,那么服务化注定是失败的,服务化的关键在于剥离基础业务能力,进行领域模型的建立,达到长治久安,如果你招聘的架构师不去深入看你的代码,而仅仅提供一套框架,那么对不起,这哥们很有可能是个大骗子。

5.服务化一定要远程部署吗?

答:假如你的组织结构没有庞大到一定级别,系统量也不大,那么我认为只要把业务模型抽象好,封装成不同的模块,比如JAVA,提供二方库形式的JAR包依赖就是一个很好的选择,毕竟远程部署之后,会对你的开发人员造成一定的困惑,等以后需要远程化了,因为你的业务建模已经做好,远程不是那是自然而然的事情。。。

今天先谈到这里,也许我的观点未必正确,欢迎大家拍砖。

另外,本文的内容和本人目前工作的公司,已经工作的内容毫无关系,仅仅是最近遇到的一些公司刚好都在做服务化,或者想做服务化这样的事情,由此感慨而已。

about_soa.txt · 最后更改: 2018/10/14 15:31 (外部编辑)