Component Based Rails Application 模块化的Rails_微服务以外的另一种选择

Slide 1

Slide 1 text

模块化的Rails，微服务以外的另一种选择 C B R A @Madao github.com/Madao-3

Slide 2

Slide 2 text

自我介绍 @Madao github.com/Madao-3 野生全栈工程师

Slide 3

Slide 3 text

为什什么不不选择微服务？

Slide 4

Slide 4 text

单体应⽤用优先策略略

Slide 5

Slide 5 text

最早的时候我们是这样

Slide 6

Slide 6 text

我们以为项⽬目演进项之后项⽬目会变这样

Slide 7

Slide 7 text

但其实⼀一般是这样

Slide 8

Slide 8 text

让我们来假设⼀一个场景 Controller Model Views

Slide 9

Slide 9 text

回忆⼀一下常规单体开发的历程 Controller Model Views

Slide 10

Slide 10 text

回忆⼀一下常规单体开发的历程 Controller Model Views Controller Model Views ontroller Model Views Controller Model Views Controller Model Views Controller Model Views Controller Model Views Controller Model Views Controller Model Views Controller Model Views Controller Model Views Controller Model Views

Slide 11

Slide 11 text

需要解决的问题 1.降低单体应⽤用的复杂度 2.避免过慢的CI 3.便便于⽣生成依赖关系图 4.减少实现过程中所需的上下⽂文内容 5.快速交付

Slide 12

Slide 12 text

那么我们有什什么办法呢？⾸首先要保证能够持续⾼高效地交付，这时候你会发现继续维持原有的单体架构是不不可⾏行行的。你需要拆分它，降低它的复杂度，并且确定拆分的边界。

Slide 13

Slide 13 text

那还不不是微服务嘛

Slide 14

Slide 14 text

如果我们可以把每⼀一个拆分出来的⼦子 Rails 应⽤用当做Gem 呢？

Slide 15

Slide 15 text

C B R A Component-Based Rails Applications

Slide 16

Slide 16 text

旧版本：http://shageman.github.io/cbra.info/ @shageman

Slide 17

Slide 17 text

http://modular-rails.samurails.com/ @T_Dnzt

Slide 18

Slide 18 text

让我们实践⼀一下

Slide 19

Slide 19 text

让我们开始我们的第⼀一步： rails new cbra cd cbra rm -rf ./app 然后

Slide 20

Slide 20 text

收⼯工！

Slide 21

Slide 21 text

还有下⽂文

Slide 22

Slide 22 text

rails plugin new engines/admin --mountable 假设我们要实现后台（admin）模块

Slide 23

Slide 23 text

然后执⾏行行 bundle install Gemﬁle

Slide 24

Slide 24 text

填充下必要的内容

Slide 25

Slide 25 text

rails g controller welcome ⾸首先 cd engines/admin

Slide 26

Slide 26 text

创建好Welcome#index 这个action 所需的内容然后编辑路路由然后打开你的 /admin 这个路路径，Tada

Slide 27

Slide 27 text

为什什么是Engines ⽬目录下的？我们⽤用组件是否为⼀一个Rails 实体来决定它所应该在的组件⽬目录：需要作为⼀一个Rails 实体服务存在的组件。或者可以直接理理解为，这是⼀一个可直接拆分为微服务的。 /engines ⽬目录「⽆无状态」，不不依赖Rails 的，或者仅负责数据的流动，或者⼀一些特定的计算。 /gems ⽬目录

Slide 28

Slide 28 text

所以项⽬目会⻓长这样根⽬目录组件实例例根⽬目录组件实例例

Slide 29

Slide 29 text

所以项⽬目会⻓长这样

Slide 30

Slide 30 text

前置内容完毕，我们来尝试思考如何拆分已有的巨⼤大单体

Slide 31

Slide 31 text

符合以下规则，我们拆成新的模块 1. 项⽬目中明显内聚的领域，拆分成模块。 2. 粒度较⼤大的服务，尝试拆分。 3. ⽤用业务域将业务逻辑分解为多个有界上下⽂文，每个上下⽂文是⼀一个模块

Slide 32

Slide 32 text

单体应⽤用 View View View View View View View View Controller Controller Controller Controller Model Model Model Routes Gemﬁle

Slide 33

Slide 33 text

单体应⽤用 View View View View View View View View Controller Controller Controller Controller Model Model Model Routes Gemﬁle Routes Gemﬁle Engine

Slide 34

Slide 34 text

Engines 主项⽬目 Engines Rails Engine

Slide 35

Slide 35 text

⽤用 Spree 举例例

Slide 36

Slide 36 text

No content

Slide 37

Slide 37 text

……

Slide 38

Slide 38 text

M V C M V C V C M V C M V C M V C M V C Engines GEMS S1 S2 S3 S4

Slide 39

Slide 39 text

系统过于庞⼤大是否会带来持续集成的负担？

Slide 40

Slide 40 text

事实上只要保证代码分割是正确的，那就只需要跑对应component 下的CI 即可。

Slide 41

Slide 41 text

真的有这样的做的公司/项⽬目吗？ https://www.joinroot.com/ ROOT 65,000多⾏行行Ruby / Rails应⽤用程序代码 135,000多⾏行行测试代码 37 个 Engine 22 个Gem 30+ ⼯工程师 https://powerhrg.com 491910 ⾏行行代码超过30个 Component https://github.com/spree/spree

Slide 42

Slide 42 text

优点更更好的代码组织模块内的代码需要的上下⽂文信息更更少随时可迁移成微服务同步/学习成本测试复杂度增加数据库迁移(Migration)依旧会很慢考虑是否模块化也需要思考成本劣势部署效率低下的问题仍未消失可以选择性的跑集成内容

Slide 43

Slide 43 text

适合的场景 1. 体量量较⼤大臃肿不不堪的单体应⽤用 2. CI 时间过⻓长的单体应⽤用 3. 频繁出现合并冲突的单体项⽬目 4. 符合合并规则的微服务

Slide 44

Slide 44 text

不不建议的场景 1. 初期项⽬目 2. 过⼩小的团队 3. 已经有良好的代码组织的项⽬目

Slide 45

Slide 45 text

如果你的项⽬目连模块化架构都⽆无法达成，为什什么你会觉得微服务能解决你的困难呢？