创业公司的我们，微服务为什么不迷信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