Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Component Based Rails Application 模块化的Rails_微服务...
Search
Madao
October 17, 2018
Technology
1
380
Component Based Rails Application 模块化的Rails_微服务以外的另一种选择
Ruby Summit 2018
Madao
October 17, 2018
Tweet
Share
Other Decks in Technology
See All in Technology
LLM時代の検索とコンテキストエンジニアリング
shibuiwilliam
2
1k
Gaze-LLE: Gaze Target Estimation via Large-Scale Learned Encoders
kzykmyzw
0
270
MCPサーバーを活用したAWSコスト管理
arie0703
0
140
薬屋のひとりごとにみるトラブルシューティング
tomokusaba
0
410
EKS Pod Identity における推移的な session tags
z63d
1
190
Oracle Base Database Service:サービス概要のご紹介
oracle4engineer
PRO
2
20k
PFEM Online Feature Flag @ newmo
shinyaishitobi
2
260
JOAI発表資料 @ 関東kaggler会
joai_committee
1
170
AIは変更差分からユニットテスト_結合テスト_システムテストでテストすべきことが出せるのか?
mineo_matsuya
5
2.9k
人を動かすことについて考える
ichimichi
2
230
2025新卒研修・Webアプリケーションセキュリティ #弁護士ドットコム
bengo4com
3
9.9k
生成AI活用のROI、どう測る? DMM.com 開発責任者から学ぶ「AI効果検証のノウハウ」 / ROI of AI
i35_267
4
140
Featured
See All Featured
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
33
2.4k
Scaling GitHub
holman
462
140k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.6k
Code Review Best Practice
trishagee
70
19k
The Cult of Friendly URLs
andyhume
79
6.5k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
183
54k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
283
13k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
890
Embracing the Ebb and Flow
colly
86
4.8k
Typedesign – Prime Four
hannesfritz
42
2.8k
Practical Orchestrator
shlominoach
190
11k
Transcript
模块化的Rails,微服务以外的另一种选择 C B R A @Madao github.com/Madao-3
自我介绍 @Madao github.com/Madao-3 野生全栈工程师
为什什么不不选择微服务?
单体应⽤用优先策略略
最早的时候我们是这样
我们以为项⽬目演进项之后项⽬目会变这样
但其实⼀一般是这样
让我们来假设⼀一个场景 Controller Model Views
回忆⼀一下常规单体开发的历程 Controller Model Views
回忆⼀一下常规单体开发的历程 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
需要解决的问题 1.降低单体应⽤用的复杂度 2.避免过慢的CI 3.便便于⽣生成依赖关系图 4.减少实现过程中所需的上下⽂文内容 5.快速交付
那么我们有什什么办法呢? ⾸首先要保证能够持续⾼高效地交付,这时候你会发现继续维持原有的单体架构是不不可⾏行行的。 你需要拆分它,降低它的复杂度,并且确定拆分的边界。
那还不不是微服务嘛
如果我们可以把每⼀一个拆分出来的⼦子 Rails 应⽤用当做Gem 呢?
C B R A Component-Based Rails Applications
旧版本:http://shageman.github.io/cbra.info/ @shageman
http://modular-rails.samurails.com/ @T_Dnzt
让我们实践⼀一下
让我们开始我们的第⼀一步: rails new cbra cd cbra rm -rf ./app 然后
收⼯工!
还有下⽂文
rails plugin new engines/admin --mountable 假设我们要实现后台(admin)模块
然后执⾏行行 bundle install Gemfile
填充下必要的内容
rails g controller welcome ⾸首先 cd engines/admin
创建好Welcome#index 这个action 所需的内容 然后编辑路路由 然后打开你的 /admin 这个路路径,Tada
为什什么是Engines ⽬目录下的? 我们⽤用组件是否为⼀一个Rails 实体来决定它所应该在的组件⽬目录: 需要作为⼀一个Rails 实体服务存在的组件。 或者可以直接理理解为,这是⼀一个可直接拆分为微服务的。 /engines ⽬目录 「⽆无状态」,不不依赖Rails
的,或者仅负责数据的流动,或者⼀一些特定的计算。 /gems ⽬目录
所以项⽬目会⻓长这样 根⽬目录 组件实例例 根⽬目录 组件实例例
所以项⽬目会⻓长这样
前置内容完毕,我们来尝试思考如何拆分已有的巨⼤大单体
符合以下规则,我们拆成新的模块 1. 项⽬目中明显内聚的领域,拆分成模块。 2. 粒度较⼤大的服务,尝试拆分。 3. ⽤用业务域将业务逻辑分解为多个有界上 下⽂文,每个上下⽂文是⼀一个模块
单体应⽤用 View View View View View View View View Controller
Controller Controller Controller Model Model Model Routes Gemfile
单体应⽤用 View View View View View View View View Controller
Controller Controller Controller Model Model Model Routes Gemfile Routes Gemfile Engine
Engines 主项⽬目 Engines Rails Engine
⽤用 Spree 举例例
None
……
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
系统过于庞⼤大是否会带来持续集 成的负担?
事实上只要保证代码分割是正确的, 那就只需要跑对应component 下的CI 即可。
真的有这样的做的公司/项⽬目吗? 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
优点 更更好的代码组织 模块内的代码需要的 上下⽂文信息更更少 随时可迁移成微服务 同步/学习成本 测试复杂度增加 数据库迁移(Migration)依旧会很慢 考虑是否模块化也需要思考成本 劣势
部署效率低下的问题仍未消失 可以选择性的跑集成内容
适合的场景 1. 体量量较⼤大臃肿不不堪的单体应⽤用 2. CI 时间过⻓长的单体应⽤用 3. 频繁出现合并冲突的单体项⽬目 4. 符合合并规则的微服务
不不建议的场景 1. 初期项⽬目 2. 过⼩小的团队 3. 已经有良好的代码组织的项⽬目
如果你的项⽬目连模块化架构都⽆无法达成, 为什什么你会觉得微服务能解决你的困难呢?
软件⼯工程没有银弹
FAQ