📚正文

当你的项目变得庞大的时候,项目的复杂度就会以指数级增长。笔者曾发表过另一篇文章,用以帮助别人理解 朝着微服务演进的必要性。这次,笔者会详细说明为什么微服化是一种已经被证实过的,并且可以让项目更容易让人理解和扩展的解决方案。接下来,我们来探究如何把 Rails 用微服务的方式拆分。

这篇文章的核心思想是如何将你的 Rails 项目拆分成微服务架构。

如果你有一个庞大的 Rails 项目,并且你很清楚这个项目需要变得简单容易扩展。那么本文将告诉你构建出 Ruby on Rails 微服务的主要理由和必要条件。

虽然将一个项目演变成微服务建有好有坏,但当你的项目变得庞大并且难以扩展的时候,你仍然需要想办法将它拆分。

微服务架构的第一个关键点在于,你的服务由各个部分组成,他们之间互不耦合,并且每个部分都可以独立成一个项目。各个部分之间的通信依靠各自暴露的 API,这样使得每个开发团队可以独立开发维护自己的部分,避免了不同团队之间可能会污染到对方的代码。

什么情况下你需要拆分了?

  • 你的测试代码会跑 20min 以上
  • models 的数量好几百甚至上千
  • 项目中有完全独立的功能模块
  • 开发人员不能够独立开发 & 部署他们自己的功能模块了

或许还有更多的原因,但上述的条件是你一定不能忽视的。

当然,不用微服务架构的话,你也可以多部署一些服务器,或者实现一些执行效率更高的技术。但是可以想一下,

为什么会使用微服务方式拆分项目?

microservice-based 项目由一个个独立的功能模块组成,每个功能模块有自己独立的职责。这也允许了开发团队可以各自独立开发自己的功能模块,这种本身的低耦合特性可以让每个功能模块变得更小,更简单,更容易理解,也可让新人更快地参加项目开发。最终,当项目被完全解耦拆分后,功能迭代的成本代价也将更小。新技术的引入导致的服务重写也将会变得可行。同样的,采用了微服务的跨语言特性可以让你的项目由不同语言,技术框架来完成。因此,

** 采用微服务的优势在于 **

  • 功能模块可以被复用
  • 功能模块可以独立于整个项目平稳快速部署
  • 更加容易加入新功能
  • 减少测试时间成本,主要是可以在一个独立模块里测试而不是在大项目中
  • 小项目一定比大项目更容易维护
  • 独立的功能模块让开发人员可以专注于自己的那个点
  • 更不容易改动到无关的功能模块
  • 更好的可靠性和容错性
  • 更容易迁移和升级
  • 允许技术多样性(* 语言栈不统一不一定好 – 译者注 *)
  • 任何一个服务挂掉了,都不会导致整个项目挂掉
  • 新人更容易熟悉代码

然而,只有你的项目满足了下面的条件的时候,你才可以体会到这些优势

Ruby on Rails 项目拆分成为微服务架构的必要前置条件

  • 你的项目代码一定是 Clean Code

因为你的项目拆分成了微服务架构之后,从业务层面看项目本身的是和之前一样。但如果你的代码写得很糟糕,项目跑在了很糟糕的代码上。你的项目将很难按照预期去迭代。

  • 你的项目应该合理地按照正确的功能边界去拆分

当你开始构建微服务架构的时候,你的项目一定会包含了许多 “微服务” 组件,每个组件的运行应该是畅通无阻的,并且他们之间的运行不会互相干扰。只要能按照准确、良好的定义去拆分出来,你就能做到这一点。规划好组件的每个任务和与该任务相关的工作,以获得最佳结果。确保你拆分出来的每个组件都各自独立。

  • 你的项目应该有备份

在你的微服务项目中,无论何时,其中的组件都有可能会挂掉,但你的整个项目却还是可以一直跑。整个项目中,某个(多个)功能组件挂掉了可能会给你带来一系列问题。

你需要给你的项目在这个方面做好规划以保证挂的时间可以最小。这当然就需要你能够做好对应的监控,当有异常产生的时候可以及时应对。这种策略可以让工程师们在用户感知到服务挂掉之前处理好。

当你的做好这些准备的时候,就可以开始拆了。

如何把你的 Rails 项目拆掉呢?

正常情况下,一个 Rails 项目会被分层,通常是:表示层 (presentation), 业务逻辑层 (business logic), 数据连接层 (data access)。企业级项目通常也就被分为上述三层。你的微服务组件也就分成了这三类。

  • Presentation Layer

响应 Http 请求和实现(REST)API 或者 Web UI。在项目中通常会有复杂的用户交互接口。

  • Business logic layer

实现业务逻辑的组件

  • Data-access layer

基础连接的组件,通常是连接数据库或者消息中间件。

同样,笔者也推荐阅读 Syndicode 的 Rails 微服务