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