创业公司的我们,微服务为什么不迷信Spring-Cloud

业务背景

我们是一家SaaS软件研发公司,我们服务的客户主要是企业为主,对网站速度,网站安全性,以及交易吞吞吐有要求,经常出现平常网站压力很小,做一波活动,压力增加成百上千倍(最担心客户广告投放过猛,直接压垮我们系统),这种是家常便饭,各种活动走一波,我们压力山大,对系统性能和可靠性要求很高。说简单的点,前端页面灵活多变,后端系统不只是要安全可靠,还要做到能屈能伸,这可把我们技术小哥哥可愁坏了。而且我们还遇到很多创业公司相同的问题,人手不够,一个人顶几个人用。没有谁是专职只做某件事。你这时候可能是程序员,下一秒可能就成了系统工程师,做运维。

技术背景

我们技术栈主要是PHP+Java+Go+Python

在这种业务复杂多变的背景下,我们计划把系统进行重构,经过研究讨论,系统架构走微服务路线。 我们前端技术主要是PHP(CodeIgniter)实现的,后端服务有讨论用Golang和java(Python就没考虑了,我们主要拿Python来开发后端其他任务居多),后来参考了HR的建议,我们还是选择了Java,只怪Golang招人不太好招,Golang实现的业务,就是我们几个老鸟来维护一些性能关键的业务,其他还是用Java来实现,而且对于我们这种创业公司的人来说,费用是第一考量。最终选择了用Java来实现微服务。

微服务选型

微服务这块,我们接触的比较早的是Facebook开源出来的Thrift,自建RPC微服务,后来服务越来越多,服务治理成了一个大问题。 当时做服务治理好点的就是阿里巴巴出的Dubbo(包括当当改造的Dubbox),阿里当时一直没有重视这个东西,直接停止了维护, 连Spring都是用的比较老的版本,当时就没有切换,将就着用Thrift做的RPC服务。 后来Spring-cloud出来,很多公司的技术都表看好这个,也有很多公司开始对这个报有很高的期望,由于Spring-cloud新东西出来, 需要学习和验证的东西很多,而我们团队有个问题,技术栈比较杂,有些擅长Java有些擅长PHP,有些擅长Golang,不适合强制统一用java来开发,所以一直没有重视,只是能远观参考,我们不会像其他创业公司拿样子一股脑的去追求新技术,其实还有个最最重要的问题是成本考虑,招聘个好用的Java程序员,是PHP的2倍工资,老板穷,得为老板考虑。

直到腾讯开源出了Tars,以及后来阿里重启了Dubbo的维护,才看到了希望。 我们团队是比较看好Tars的,Tars比较符合我们团队的技术栈,同时他的运维架构很强大,不需要重新发明轮子。

项目改造

由于我们服务开发是Java和Golang并行的,所以服务改造这块,工作量还是挺大的,做不到一次性完全切换,只能随着时间推移, 慢慢的把新服务启用,旧服务一步步退役。新旧服务并行运行。我们的做法是,在前端服务中间层,做了个服务路由转发功能, 集中火力做了个类似服务代理的这么个东西,服务代理,就是负责将所有服务调用集中在一起,面向应用就是纯PHP API,通过这个代理 层转发到不同的应用实现,调用Thrift还是调用Tars的,性能方面稍微有点点损失,毕竟需要做一层路由,但是这个在可接受范围内。 这样子,我们可以不慌不忙的把服务从Thrift切换到Tars,程序员该吃吃该喝喝该睡睡,不加班不熬夜。

转载于:https://my.oschina.net/ifeisu/blog/3031652

你可能感兴趣的:(php,golang,后端)