微服务是如何拯救我的

原文：How Microservices Saved My Small SaaS Business

作者：Ynon Perek

翻译：Vincent

译者注：作者通过阅读文章了解了微服务，但也知道了微服务带来的复杂性，所以对微服务是持反对态度的，但是等到真正使用了以后，才了解微服务带来的好处，那你是不是对微服务也有不好的认识呢？有的话，看看作者是如何改变自身的态度。以下为译文。

最近我阅读了很多关于微服务的文章，知道想要实现微服务是如何的困难，因此很长一段时间，我对微服务是持反对态度的。直到认识到微服务给负责维护单体架构的开发人员提供了一些其他架构所不能提供的东西以后，我的立场才发生了转变。

维护单体架构有哪些问题

我的框架选择是服务端使用Rails和React，客户端用的是Redux。如果需要尽可能快的实现新功能，而且尽可能容易的编写和运行测试案例（Rails现在也集成了Capybara），这个框架无疑是个很好的选择，因为它使得代码更稳定，客户因此也很高兴。

但是，当我试图扩大规模，添加更多的开发人员来帮助维护和改进代码时，问题就出现了。

事实证明，对于大多数的开发人员来说，要想读懂别人的代码是一件很困难的事，如果框架的使用度很低（这里介绍的Rails框架市场份额就很少），那么想要读懂就更加困难了。框架使用度低其实根本不算问题，真正的问题是工资。由于大公司和一些看起来很酷的创业公司也似乎都在招人，我没办法与他们竞争人才，因此无法招聘到优秀的员工，所以才会遇到各种问题。

由于预算的限制，我不可能招募到顶尖的人才，也没办法让他们在开始操作生产环境之前提供2-3个月的时间来学习代码。

所以我尝试用自由职业人员去解决问题

这种尝试的结果最终以失败告终，而且失败得很惨。因为对于员工来说，学习代码就已经是一件很困难的事情了，对于自由职业者来说，这种难度最起码增加了十倍。由于他们手上有很多其它的项目，而且他们也知道只有当工作完成以后才会得到报酬，所以当他们意识到你的工作比下一个人的工作要困难得多的时候，他们压根就不会理你。

而当你花了几个小时跟自由职业者解释清楚了代码是如何运行的，需要做哪些调整之后，代码都放在了他们的电脑上，当你想要了解进度时，自由职业者的回应速度可能会很慢。

随着时间的推移，为了尽量减少这些风险，我尝试着让一名自由职业者在办公室里工作，或者只给他们部分代码。最终我还是放弃了，因为成本上升了，但是结果却依然很糟糕。

微服务出现了

后来直到有一天，一位朋友想帮我实现一个功能，但他想用PHP去实现。我决定给他一个机会，然后设置了nginx，这样“他的”页面就可以用PHP服务了。我还构建了一个专用的Rails控制器，这样就相当于给他提供了一个单独的DB schema和一个简单的API。

新的nginx看起来是这样的：

现在只要想访问/php文件夹下面的php文件的用户最终都会得到PHP服务了。由于PHP服务和单体架构都在同一个域上运行，所以浏览器会发送相同的session和cookie。

这样身份验证方案就变得非常的简单了：PHP发送给cookie专用的Rails控制器，如果action验证通过的话，Rails会将结果返回回来。下面是Rails代码的简化版本：

find_resource方法的实现是一段很长的case块，在这里详细介绍的话会显得很无趣。

一年以后

在做了第一次尝试的一年之后，终于与自由职业者成功的合作开发出来一个系统，而且现在双方的风险也尽可能的降低了。

我可以使用一个定义很好的API为任务编写详细的规范。通常我会让自由职业者用他们喜欢的语言实现JavaScript API和后端。

服务和单体架构的整合仍然是一个难题，但并没有那么糟糕。只要有可能，我们将使用客户端代码来管理事务逻辑。对于异步任务，我们将使用RabbitMQ，对于像真正需要事务的这样极少数情况，我们会构建一个专用的后端API。

现在这个方法面临的主要问题是运维。随着时间的推移，自由职业者逐渐完成了他们的工作，而我就负责对他们的代码就行运维(这并不是一件容易的事)。然而，通过要求他们做一个完整的测试套件，这样风险也可以降低。

微服务尽管有这样或那样的复杂性和困难，但是它却是我和其他人一起工作的最简单的方法，它不会增加额外的雇佣成本，自由职业者也不会冒着风险。我强烈建议尝试一下这种架构，特别是对于单独的开发人员。