从Ruby巨石架构迁移到Go微服务的经验教训

Niket是一个拥有9年Web开发经验的程序员，2013年开始使用Go语言，这个谈话是有关其从Ruby的monolithic(巨石、整体性和铁板一块)架构切换到Go语言 microservice(微服务)架构过程中的经验教训：

From a Ruby monolith to microservices in Go, lesso

将解决单一问题的单一目标的业务服务作为微服务是微服务架构的特点。Niket在Beehively工作，这是一个流行的家长沟通和学分与考勤管理的在线平台，Beehively是一个Ruby应用，多年来，它已经增长为包含很多特点的网站，包括成绩单生成报告与通知提醒等等，在2013年，开发团队决定从Ruby编写的巨石架构切换到Go语言与Ruby混合的微服务架构。

Ruby是一个复杂的语言，Ruby表面上美观，但有复杂的内心，就如同我们的身体。

当他们起初开始时，Ruby的强大和复杂是有用的，但是随着时间推移，语言的复杂性渗透到Beehively代码库中，当项目较小时Ruby是一个很好的语言。他们决定切换到新的语言和架构以约束代码库的复杂性。

这个谈话关于：他们为什么切换到微服务架构？为什么Go是微服务架构的好选择？

Ruby的痛苦
有三个主要点导致他们迁移离开Ruby的巨石铁板一块架构。

1.内存消耗与速度；应用许多数据缓存在内存中以提升性能，但是Ruby分配和GC回收会消耗很多时间，最终抵消了缓存带来的大幅度性能提升，他们使用UX workaround隐藏了缓慢，也买了更大的箱子，虽然正常工作一段时间，最终到达了临界点。

2.并发：在Ruby中实现并发是通过多进程使用，应用需要许多worker，每个运行在自己的进程中，这增加了他们的内存消耗。

3.兼容性测试：在他们经验中，Ruby是非常快速开发的，这是一种会破坏很多事情的方式，重要的库包会被抛弃，框架会融合入框架中，当你的产品是年轻的，那么你的产品还是有较少依赖，你可以得到解放且产品是漂亮的，但是有些时候你更需要稳定性，Go社区文化更利于稳定，且避免了破坏性的变化。

为了实现更好的用户体验和利用更现代的技术，经过几个月的工作，他们重写了代码，但是新系统仍比他们的旧系统在功能上要少一点，尽管新代码是更好，但是无法移交给他们客户，因为功能不够，所以，他们陷入一个尴尬两难境界，第二个新系统很好，但是在功能上不能完全替代第一个系统。

迁移到微服务是解决这个问题的办法。

迁移到微服务不代表重写编写整个应用程序，他们可以提出组件作为单独的应用。

三个核心组件 PDF产生器, alert系统, 和 成绩单计算grade calculator分解成三个独立的微服务。

具体可见原文....

他们使用Nginx将请求路由转发到这些微服务或主要的Ruby应用，Redis是一个结合主应用和微服务的有效工具，Go的微服务将Ruby应用看成是一个API客户端或上游代理。需要简单的授权，微服务和主应用可以独立扩展。

Go在部署方面很简单，只要构建 rsync和通过upstart重启。

在2013切换以后，Beehively找到了干净漂亮的新架构，这里是他们经验收获：
1. Go语言是一个编写Web服务简单伟大的语言，它特别适合微服务，这不但包括指GO语言本身，还有围绕它的一些工具和社区文化。

2.相比从零重写整个应用程序，你可以针对性的将一些组件使用Go微服务替代，从而减少工作量，但是又带来更多好处，到目前为止，他们还没有减少任何客户依赖的功能。

3.即使新的架构需要部署多个服务，Go使得部署简单，这从系统管理角度看很关键。

对于那些因为复杂导致开发变慢的团队，他们高度推荐使用Go语言改写。