【译】将你的Rails项目拆分成微服务架构
原文链接： https://dev.to/iriskatastic/split-your-rails-app-using-microservices-ckl
📚正文
当你的项目变得庞大的时候，项目的复杂度就会以指数级增长。笔者曾发表过另一篇文章，用以帮助别人理解朝着微服务演进的必要性。这次，我会详细说明为什么微服化是一种已经被证实过的，并且可以让项目更容易让人理解和扩展的解决方案。接下来，我们来探究如何把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微服务。
