作者chal ( )
微服務似乎可以改善一點這方面的問題
系統開發有點像是公司還很小的時侯
當你公司還很小的時侯
某個職員要當客服 又要兼倉管 又要兼銷售
所以這個職員可以拿到各種不同的數據
當公司開始變大以後
就會有財務部 客服部 商品部
每個部門的數據再也不像小公司時可以任意取得
每個部門內部各自處理管理
其他部門不用管另一個部門也不用知道他們怎麼管理
部門之間的溝通要透過窗口或部長
當系統一開始小的時候
就像小公司校長兼撞鐘
一包系統可以同時去存取會員資料與商品資料與物流資料
當系統變大以後
其實也應該像小公司變大公司那樣劃分不同部門
把各個不同性質的資料抽出來變成微服務
這樣的好處就是減少耦合
服務內部不管如何改變
只要對外保持一致就不用擔心
如果有那種萬年不用更動的服務
那就讓他安靜的待在角落 不要管他
新進人員也不用花心力去理解那個服務
每個服務很小
小就代表容易理解也容易測試也容易改動
不同部門的資料互相隔離 也更安全
一間公司變大很自然就會劃分成各個部門
一個系統變大非程式人員卻不容易理解為什麼要拆開成不同包
想像有一間 5000人的大公司
每個人都可以任意去各部門拿資料拿數據
而任何部門有任何變動都要想辦法去確定這5000人都確定這個變動
這就是程式的世界
系統寫久了 5000支程式是有可能的
任何變動都要確定這5000程式沒受影響
那改起來就是災難
自然而然很不想去亂動
或者動不動就想重寫
用公司變大去解釋或許可以讓人理解
公司變大了要有不同部門
可以把部門的小變動固定在某個部門內
不會去影響全公司
當然微服務要弄起來也要有一些成本
所以小公司才校長兼撞鐘
--
→ MoonCode1樓別 11/09 22:52
→ tsao12112樓你用過微服務？ 11/09 23:46
→ a128389103樓好奇 台灣的公司 用微服務的多嗎… 11/10 00:27
tzouandy28184樓冗言贅字太多 11/10 01:22
abccbaandy5樓2023了還在吹微服務，面試都很少提這東西了 11/10 01:28
qwer3388596樓沒那屁股別吃那瀉藥 11/10 01:35
其實我不是在講很嚴格的微服務
微服務如果單論工具的話
其實spirng cloud 出的工具
大概花一點時間學不會太難
工具主要是提供服務之間的溝通與發現
其實就是一些工具設定
但我覺得微服務主要的難點有二個
一個是 服務怎麼切
以及
系統小時候你沒機會用微服務 系統大的時成本太大
服務怎麼切有一個作法是DDD
裡面又延伸很多術語
DDD是早於微服務的
我也不是全部都懂就不多說了
DDD的副標是
軟體核心複雜度的解決方法
我覺得這個才是治本的作法
有很多管理複雜度的作法
比如說去code review 人員教育
都是比較事後 且要公司有餘裕的條件下才能做的治標作法
我是覺得程式會亂是出於每個人的思考都是不同的
還有時間壓力
所以要靠事後的管理來維持程式的不混亂是很難的
而且成本不小 可以提昇品質 但很難維持
換個主管說不定政策就變了
有的程式是老鳥寫的 早已離職
有的程式是菜鳥寫的 沒辦法寫的好
時間壓力下能動就上線是台灣公司常態
另外程式的寫法有百百種
不同的思考也可以完成相同的目的
這也是程式的一種亂
既然亂是改變不了的
那我們就不該想的是讓他不亂
而是說亂是一定會亂的 但是控制他的大小
就像你有一個像汽車一樣大的毛線球
非常紊亂而且預期汽車毛線球還會一直長大
VS 你有300顆棒球大小的毛線球
而主要核心的毛線球可能十來顆
你控制的不是亂 而是大小
很小的毛線球再怎麼亂你也有能力救
另一個難題就是系統很大時才要改微服務
比如說把會員服務抽出來（不同DB）
你以前撈會員資料是用sql撈
現在要改用token串api接json
那可能5000支程式裡有幾百支直接間接用到的程式都要改
花半年改了以後
老闆問你花半年的時間 系統怎麼沒有任何變化
所以我也不是鼓勵大老系統去改這個
而是說
作法上概念可以往這方面接近
例如新的業務就不要再加在原來的大老系統上
總之
我不是在講很嚴格定義的微服務
而是在說
控制系統越來越大越來越亂的方法
可以有兩個維度
一個做法是專注在讓它不要亂
另一個是專注在讓它不要長大
想辦法讓他不要長大
小東西就算亂 也亂不到那裡去
有天你想好好整理 小東西也是看得到隧道的光亮
控制大小是利用框架與工具
控制品質則是主管與人的思考教育
我是覺得控制大小才是長遠的解決之道
但也不是說兩者衝突
其實也可以並行
只是在不同時間點的優先順序不同
yamiodymel7樓看得出來你大概也知道微服務有多雷 11/10 03:06
mozume8樓會有原原po問題的千萬別用微服務，連單體服務都搞不好的 11/10 06:05
→ mozume9樓上微服務只會是災難 11/10 06:05
DrTech10樓不管是服務還是微服務，你的概念就是模組化把解偶合，減少 11/10 08:10
→ DrTech11樓每次變更需要處理的工作量而已。 重點是人的頭腦有沒有這 11/10 08:10
→ DrTech12樓種概念：沒有這種工作概念，不管你是用什麼服務，微服務， 11/10 08:10
→ DrTech13樓還是把自己搞死。 11/10 08:10
→ DrTech14樓這就是為什麼，有些人覺得：怎麼可能專案完成越多，事情與 11/10 08:12
→ DrTech15樓壓力越多。有些人覺得，專案完成越多，事情越多的差異。不 11/10 08:12
→ DrTech16樓同的人，做事情的觀念決定了一切。 11/10 08:12
devilkool17樓我只寫過服務而已，原來微服務過氣了嗎 11/10 09:12
lazarus112118樓微服務我覺得只有server掛掉有差 11/10 09:26
→ lazarus112119樓其他還是看開發習慣吧 11/10 09:26
WTS2accuracy20樓微服務大部分都是拿來嘴砲的 會用的少之又少 11/10 09:39
→ WTS2accuracy21樓多的是沒多少成效甚至比不拆還慘 11/10 09:40
→ WTS2accuracy22樓別網路文章看一看就高潮吹上天 實際沒這麼簡單 11/10 09:42
sniper282423樓差低 11/10 10:16
happy864924樓推原po，講得很好 11/10 11:15
→ happy864925樓感覺很多人只是沒遇過微服務>單體的狀況 11/10 11:15
→ happy864926樓或是沒在成熟的微服務體系待過而已 11/10 11:15
→ happy864927樓微服務在處理的並不只是程式的問題 11/10 11:15
→ happy864928樓但可能大部分台灣公司的業務大小就是不會需要微服務吧 11/10 11:17
→ mirror022729樓微服務不就是你原本只要管一個服務 拆開之後變成要管 11/10 11:31
→ mirror022730樓10個微服務 11/10 11:31