Re: [討論] 系統越開發越多，負責的東西越來越多

看板Soft_Job作者 ( )時間5月前 (2023/11/09 22:16), 5月前編輯推噓19(24推 5噓 65→)
留言94則, 36人參與, 5月前最新討論串5/5 (看更多)
微服務似乎可以改善一點這方面的問題 系統開發有點像是公司還很小的時侯 當你公司還很小的時侯 某個職員要當客服 又要兼倉管 又要兼銷售 所以這個職員可以拿到各種不同的數據 當公司開始變大以後 就會有財務部 客服部 商品部 每個部門的數據再也不像小公司時可以任意取得 每個部門內部各自處理管理 其他部門不用管另一個部門也不用知道他們怎麼管理 部門之間的溝通要透過窗口或部長 當系統一開始小的時候 就像小公司校長兼撞鐘 一包系統可以同時去存取會員資料與商品資料與物流資料 當系統變大以後 其實也應該像小公司變大公司那樣劃分不同部門 把各個不同性質的資料抽出來變成微服務 這樣的好處就是減少耦合 服務內部不管如何改變 只要對外保持一致就不用擔心 如果有那種萬年不用更動的服務 那就讓他安靜的待在角落 不要管他 新進人員也不用花心力去理解那個服務 每個服務很小 小就代表容易理解也容易測試也容易改動 不同部門的資料互相隔離 也更安全 一間公司變大很自然就會劃分成各個部門 一個系統變大非程式人員卻不容易理解為什麼要拆開成不同包 想像有一間 5000人的大公司 每個人都可以任意去各部門拿資料拿數據 而任何部門有任何變動都要想辦法去確定這5000人都確定這個變動 這就是程式的世界 系統寫久了 5000支程式是有可能的 任何變動都要確定這5000程式沒受影響 那改起來就是災難 自然而然很不想去亂動 或者動不動就想重寫 用公司變大去解釋或許可以讓人理解 公司變大了要有不同部門 可以把部門的小變動固定在某個部門內 不會去影響全公司 當然微服務要弄起來也要有一些成本 所以小公司才校長兼撞鐘 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.170.183.199 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1699539414.A.6D2.html
→
11/09 22:52, 5月前 , 1F
別
11/09 22:52, 1F
→
11/09 23:46, 5月前 , 2F
你用過微服務？
11/09 23:46, 2F
→
11/10 00:27, 5月前 , 3F
好奇 台灣的公司 用微服務的多嗎…
11/10 00:27, 3F
噓
11/10 01:22, 5月前 , 4F
冗言贅字太多
11/10 01:22, 4F
推
11/10 01:28, 5月前 , 5F
2023了還在吹微服務，面試都很少提這東西了
11/10 01:28, 5F
噓
11/10 01:35, 5月前 , 6F
沒那屁股別吃那瀉藥
11/10 01:35, 6F
其實我不是在講很嚴格的微服務 微服務如果單論工具的話 其實spirng cloud 出的工具 大概花一點時間學不會太難 工具主要是提供服務之間的溝通與發現 其實就是一些工具設定 但我覺得微服務主要的難點有二個 一個是 服務怎麼切 以及 系統小時候你沒機會用微服務 系統大的時成本太大 服務怎麼切有一個作法是DDD 裡面又延伸很多術語 DDD是早於微服務的 我也不是全部都懂就不多說了 DDD的副標是 軟體核心複雜度的解決方法 我覺得這個才是治本的作法 有很多管理複雜度的作法 比如說去code review 人員教育 都是比較事後 且要公司有餘裕的條件下才能做的治標作法 我是覺得程式會亂是出於每個人的思考都是不同的 還有時間壓力 所以要靠事後的管理來維持程式的不混亂是很難的 而且成本不小 可以提昇品質 但很難維持 換個主管說不定政策就變了 有的程式是老鳥寫的 早已離職 有的程式是菜鳥寫的 沒辦法寫的好 時間壓力下能動就上線是台灣公司常態 另外程式的寫法有百百種 不同的思考也可以完成相同的目的 這也是程式的一種亂 既然亂是改變不了的 那我們就不該想的是讓他不亂 而是說亂是一定會亂的 但是控制他的大小 就像你有一個像汽車一樣大的毛線球 非常紊亂而且預期汽車毛線球還會一直長大 VS 你有300顆棒球大小的毛線球 而主要核心的毛線球可能十來顆 你控制的不是亂 而是大小 很小的毛線球再怎麼亂你也有能力救 另一個難題就是系統很大時才要改微服務 比如說把會員服務抽出來（不同DB） 你以前撈會員資料是用sql撈 現在要改用token串api接json 那可能5000支程式裡有幾百支直接間接用到的程式都要改 花半年改了以後 老闆問你花半年的時間 系統怎麼沒有任何變化 所以我也不是鼓勵大老系統去改這個 而是說 作法上概念可以往這方面接近 例如新的業務就不要再加在原來的大老系統上 總之 我不是在講很嚴格定義的微服務 而是在說 控制系統越來越大越來越亂的方法 可以有兩個維度 一個做法是專注在讓它不要亂 另一個是專注在讓它不要長大 想辦法讓他不要長大 小東西就算亂 也亂不到那裡去 有天你想好好整理 小東西也是看得到隧道的光亮 控制大小是利用框架與工具 控制品質則是主管與人的思考教育 我是覺得控制大小才是長遠的解決之道 但也不是說兩者衝突 其實也可以並行 只是在不同時間點的優先順序不同
推
11/10 03:06, 5月前 , 7F
看得出來你大概也知道微服務有多雷
11/10 03:06, 7F
推
11/10 06:05, 5月前 , 8F
會有原原po問題的千萬別用微服務，連單體服務都搞不好的
11/10 06:05, 8F
→
11/10 06:05, 5月前 , 9F
上微服務只會是災難
11/10 06:05, 9F
推
11/10 08:10, 5月前 , 10F
不管是服務還是微服務，你的概念就是模組化把解偶合，減少
11/10 08:10, 10F
→
11/10 08:10, 5月前 , 11F
每次變更需要處理的工作量而已。 重點是人的頭腦有沒有這
11/10 08:10, 11F
→
11/10 08:10, 5月前 , 12F
種概念：沒有這種工作概念，不管你是用什麼服務，微服務，
11/10 08:10, 12F
→
11/10 08:10, 5月前 , 13F
還是把自己搞死。
11/10 08:10, 13F
→
11/10 08:12, 5月前 , 14F
這就是為什麼，有些人覺得：怎麼可能專案完成越多，事情與
11/10 08:12, 14F
→
11/10 08:12, 5月前 , 15F
壓力越多。有些人覺得，專案完成越多，事情越多的差異。不
11/10 08:12, 15F
→
11/10 08:12, 5月前 , 16F
同的人，做事情的觀念決定了一切。
11/10 08:12, 16F
推
11/10 09:12, 5月前 , 17F
我只寫過服務而已，原來微服務過氣了嗎
11/10 09:12, 17F
推
11/10 09:26, 5月前 , 18F
微服務我覺得只有server掛掉有差
11/10 09:26, 18F
→
11/10 09:26, 5月前 , 19F
其他還是看開發習慣吧
11/10 09:26, 19F
噓
11/10 09:39, 5月前 , 20F
微服務大部分都是拿來嘴砲的 會用的少之又少
11/10 09:39, 20F
→
11/10 09:40, 5月前 , 21F
多的是沒多少成效甚至比不拆還慘
11/10 09:40, 21F
→
11/10 09:42, 5月前 , 22F
別網路文章看一看就高潮吹上天 實際沒這麼簡單
11/10 09:42, 22F
推
11/10 10:16, 5月前 , 23F
差低
11/10 10:16, 23F
推
11/10 11:15, 5月前 , 24F
推原po，講得很好
11/10 11:15, 24F
→
11/10 11:15, 5月前 , 25F
感覺很多人只是沒遇過微服務>單體的狀況
11/10 11:15, 25F
→
11/10 11:15, 5月前 , 26F
或是沒在成熟的微服務體系待過而已
11/10 11:15, 26F
→
11/10 11:15, 5月前 , 27F
微服務在處理的並不只是程式的問題
11/10 11:15, 27F
→
11/10 11:17, 5月前 , 28F
但可能大部分台灣公司的業務大小就是不會需要微服務吧
11/10 11:17, 28F
→
11/10 11:31, 5月前 , 29F
微服務不就是你原本只要管一個服務 拆開之後變成要管
11/10 11:31, 29F
→
11/10 11:31, 5月前 , 30F
10個微服務
11/10 11:31, 30F
推
11/10 11:35, 5月前 , 31F
我們公司拆完之後發現外部耦合變得有點嚴重XD
11/10 11:35, 31F
→
11/10 11:35, 5月前 , 32F
想改api都不確定會不會哪裡有別支呼叫
11/10 11:35, 32F
→
11/10 11:36, 5月前 , 33F
不過應該是可以從文件管理層面解決
11/10 11:36, 33F
推
11/10 12:20, 5月前 , 34F
說微服務是嘴炮的 應該是忘了加”在台灣” 這個條件
11/10 12:20, 34F
推
11/10 12:22, 5月前 , 35F
樓上, Amazon影音串流那邊都寫文章說把微服務換回單體反
11/10 12:22, 35F
→
11/10 12:22, 5月前 , 36F
而省很多錢了
11/10 12:22, 36F
→
11/10 13:07, 5月前 , 37F
微服務用在機台單一方面還可以啦 因為改動不大 通常也
11/10 13:07, 37F
→
11/10 13:07, 5月前 , 38F
只會丟資料收資料
11/10 13:07, 38F
推
11/10 13:09, 5月前 , 39F
上面那個管10個微服務的，代表跟本不需要拆
11/10 13:09, 39F
推
11/10 15:31, 5月前 , 40F
根本問題還是內聚力和粒度阿
11/10 15:31, 40F
推
11/10 15:43, 5月前 , 41F
推
11/10 15:43, 41F
→
11/10 17:26, 5月前 , 42F
微服務跟單體是權衡取捨 無腦推的根本實際經驗吧
11/10 17:26, 42F
→
11/10 17:27, 5月前 , 43F
*沒實際經驗
11/10 17:27, 43F
推
11/10 17:28, 5月前 , 44F
推
11/10 17:28, 44F
→
11/10 17:51, 5月前 , 45F
推DrTech
11/10 17:51, 45F
推
11/10 18:42, 5月前 , 46F
微服務如果亂切或是沒有搞懂系統未來的走勢很容易
11/10 18:42, 46F
→
11/10 18:42, 5月前 , 47F
陷入微服務架構的缺點，微服務有些優點沒被提到，
11/10 18:42, 47F
→
11/10 18:42, 5月前 , 48F
實作的語言執行的系統都不需要考量其他服務。當然
11/10 18:42, 48F
→
11/10 18:42, 5月前 , 49F
在小公司或是一個人負責一堆微服務的時候會覺得用
11/10 18:42, 49F
→
11/10 18:42, 5月前 , 50F
單體的方式開發比較快，比起開API給其他微服務呼叫
11/10 18:42, 50F
→
11/10 18:42, 5月前 , 51F
，單體內call function在開發上快多了
11/10 18:42, 51F
推
11/10 20:24, 5月前 , 52F
軟體就是會成長，不可能避免的
11/10 20:24, 52F
→
11/10 20:24, 5月前 , 53F
不要亂就像你說的不能每一個人都有相同的存取權限
11/10 20:24, 53F
→
11/10 20:24, 5月前 , 54F
所以才有部門這種東西做為權限的最小單位
11/10 20:24, 54F
推
11/10 20:28, 5月前 , 55F
你後面補充的DDD那些就一種管理方式
11/10 20:28, 55F
→
11/10 20:28, 5月前 , 56F
對於一些team來說合適，有些不合適
11/10 20:28, 56F
→
11/10 20:28, 5月前 , 57F
跟review還有人員教育比起來，更偏重文化的部分
11/10 20:28, 57F
→
11/10 20:28, 5月前 , 58F
你這邊的舉例可以說是相當不合適
11/10 20:28, 58F
推
11/10 21:19, 5月前 , 59F
DDD放在這裡不會不適合吧？DDD很大部分就是在探討doma
11/10 21:19, 59F
→
11/10 21:19, 5月前 , 60F
in boundary/bounded context的拆分
11/10 21:19, 60F
→
11/10 21:19, 5月前 , 61F
再說它不只是一種管理方式，它是一種軟體工程中的設計
11/10 21:19, 61F
→
11/10 21:19, 5月前 , 62F
方式
11/10 21:19, 62F
→
11/10 22:12, 5月前 , 63F
「任何部門有任何變動都要想辦法去確定這5000人都確定
11/10 22:12, 63F
→
11/10 22:12, 5月前 , 64F
這個變動」不用啊, 製造部最大, 他說了算
11/10 22:12, 64F
綜合說一下想法 我沒在國外待過所以只是猜想與淺見 國外會流行微服務應該是因為流量 因為微服務被設計成很容易自動擴展 而微服務可以針對核心流量業務去擴展 比如購物網站的流量可能集中在商品服務 那會員服務就沒必要用相同的規模去擴展 針對某服務更有效率的擴展 也更省錢 國外有流量的公司自然也有人手去做微服務 就變成正的循環 而台灣2300萬人很少有大到需要去做微服務的流量 沒有流量也就沒錢請夠多的IT去搞微服務 之所以沒提微服務的其他優點 是因為我也不是在在推微服務 而是在講越來越大 越來越亂的系統該怎麼處理比較好 程式的很多概念都很像 只是名詞不一樣 實務作法不一樣 但這些不同也是很關鍵的不同 比如說模組化也是一種拆分重用 但還是不一定能避免混亂 例如新人根本不知道有這個模組 或者老人知道 但不想用這個模組 可能覺得要再加工嫌麻煩之類的 自己直接寫方法處理比較快 久而久之類似的模組與方法一堆 也是亂 還是要依靠教育訓練與老鳥的品德 但如果從物理上就去阻絕 資料根本不在相同的DB上 這才能更有力量去阻絕混亂 觀念會紅起來一定有他的道理 如果台灣因為流量沒那麼大就捨棄這個觀念就有點可惜 如果原生目的不是為了處理流量 未來也不會 那就不用做很嚴格完整的微服務 但可以去接近 不同業務 不同AP 不同DB 用物理阻絕混亂 在人類的世界 如果一個公司成長到十幾人 而不劃分部門就容易查覺混亂 權責問題 安全問題 命令傳導混亂 自然而然就會把人劃分成不同部門工作 但一些沒寫過程式的主管卻不容易理解程式為什麼會亂 你改一個變動 理論上要測過所有的程式 都還不一定能保證沒問題 改一個變動要確認5000支程式都沒受影響 VS 改一個變動只要確認50支程式沒受影響 這是工作心理健康問題 50支程式你會更願意去把它變得更好 5000支程式你會想說不要亂動 能跑就好 或者你會想說 我搞懂這5000支程式都要半年以後了 不如我們重寫某一塊比較快 所以保持服務儘量小 那應該是很自然的 權衡取捨 就像小公司校長兼撞鐘 大公司有不同部門那樣 如果你是永遠的小公司 或者你是大公司但業務固定不會擴展 作業流程萬年不變 那其實也沒必要特意再花時間去劃分不同部門 的確是不適用所有的情況 ※ 編輯: chal (1.170.183.199 臺灣), 11/11/2023 00:05:00
→
11/11 12:51, 5月前 , 65F
感覺你以為劃分了部門就不會亂
11/11 12:51, 65F
→
11/11 12:52, 5月前 , 66F
你再去看一次原篇第一段提出的問題，根本不是任何開發方
11/11 12:52, 66F
→
11/11 12:52, 5月前 , 67F
法可以解決的
11/11 12:52, 67F
→
11/11 12:53, 5月前 , 68F
給你一套神級開發方法，你就能一人扛整個公司的全部系統
11/11 12:53, 68F
→
11/11 12:53, 5月前 , 69F
開發加維運嗎
11/11 12:53, 69F
→
11/11 12:56, 5月前 , 70F
整篇我只看到紙上談兵吹微服務好處，無視微服務本身的開
11/11 12:56, 70F
→
11/11 12:56, 5月前 , 71F
發成本，你真的用過？
11/11 12:56, 71F
→
11/11 12:57, 5月前 , 72F
這種吹觀念實際上對讀者沒幫助的文章網路上一堆
11/11 12:57, 72F
→
11/11 12:58, 5月前 , 73F
跟推廣企業引入大數據就可以怎樣怎樣，沒什麼差別
11/11 12:58, 73F
→
11/11 13:01, 5月前 , 74F
有聽過自從引入微服務，公司裁了幾個工程師節省成本的？
11/11 13:01, 74F
→
11/11 13:01, 5月前 , 75F
應該都是成本反而更高
11/11 13:01, 75F
推
11/11 14:38, 5月前 , 76F
有哪個開發流程是為了節省成本的?
11/11 14:38, 76F
噓
11/11 15:46, 5月前 , 77F
.......一群井蛙，沒實作過微服務的，不懂真的可以閉嘴!!
11/11 15:46, 77F
→
11/11 15:47, 5月前 , 78F
偶然看到這版，進來看一下，思維水準都太低端了...
11/11 15:47, 78F
→
11/11 16:35, 5月前 , 79F
樓上不要只會嘴，發一篇有水準的來看看啊
11/11 16:35, 79F
推
11/11 20:10, 5月前 , 80F
他一定不會發的啊（攤手）
11/11 20:10, 80F
推
11/12 12:39, 5月前 , 81F
有人在說Amazon那篇文章，那篇根本上是因為要反覆在
11/12 12:39, 81F
→
11/12 12:39, 5月前 , 82F
workflow framework 中不同step 重複存取object sto
11/12 12:39, 82F
→
11/12 12:39, 5月前 , 83F
rage 的資料，所以可能耗費多餘的IO跟cost，但重點
11/12 12:39, 83F
→
11/12 12:39, 5月前 , 84F
還是想清楚step 的切分、工具及情境的使用，並不是
11/12 12:39, 84F
→
11/12 12:39, 5月前 , 85F
說一定monolithic 就一定好。
11/12 12:39, 85F
噓
11/12 13:33, 5月前 , 86F
不管選擇走哪條路都要先想清楚需求跟人力呀，不是像很多
11/12 13:33, 86F
→
11/12 13:33, 5月前 , 87F
人那樣無腦微服務. 每個場景都有各自適用的方法
11/12 13:33, 87F
推
11/13 22:04, 5月前 , 88F
推概念解說
11/13 22:04, 88F
→
11/14 02:48, 5月前 , 89F
DDD是切分方式不是管理辦法 講引入微服務成本更高多半是
11/14 02:48, 89F
→
11/14 02:49, 5月前 , 90F
沒devops 沒自動化後面維運管理爆炸
11/14 02:49, 90F
→
11/14 02:52, 5月前 , 91F
開發流程不為了成本是為了啥? 隕石開發就好啦
11/14 02:52, 91F
推
11/14 19:19, 5月前 , 92F
微服務大多只是解決政治問題而已
11/14 19:19, 92F
→
11/14 19:20, 5月前 , 93F
成本很高的
11/14 19:20, 93F
→
11/15 15:02, 5月前 , 94F
77樓，很兇喔！
11/15 15:02, 94F
‣ 更多 chal 的文章
文章代碼(AID): #1bJEdMRI (Soft_Job)
討論串 (同標題文章)
完整討論串 (本文為第 5 之 5 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共5篇)
‣ 更多 chal 的文章
文章代碼(AID): #1bJEdMRI (Soft_Job)