微服務似乎可以改善一點這方面的問題 系統開發有點像是公司還很小的時侯 當你公司還很小的時侯 某個職員要當客服 又要兼倉管 又要兼銷售 所以這個職員可以拿到各種不同的數據 當公司開始變大以後 就會有財務部 客服部 商品部 每個部門的數據再也不像小公司時可以任意取得 每個部門內部各自處理管理 其他部門不用管另一個部門也不用知道他們怎麼管理 部門之間的溝通要透過窗口或部長 當系統一開始小的時候 就像小公司校長兼撞鐘 一包系統可以同時去存取會員資料與商品資料與物流資料 當系統變大以後 其實也應該像小公司變大公司那樣劃分不同部門 把各個不同性質的資料抽出來變成微服務 這樣的好處就是減少耦合 服務內部不管如何改變 只要對外保持一致就不用擔心 如果有那種萬年不用更動的服務 那就讓他安靜的待在角落 不要管他 新進人員也不用花心力去理解那個服務 每個服務很小 小就代表容易理解也容易測試也容易改動 不同部門的資料互相隔離 也更安全 一間公司變大很自然就會劃分成各個部門 一個系統變大非程式人員卻不容易理解為什麼要拆開成不同包 想像有一間 5000人的大公司 每個人都可以任意去各部門拿資料拿數據 而任何部門有任何變動都要想辦法去確定這5000人都確定這個變動 這就是程式的世界 系統寫久了 5000支程式是有可能的 任何變動都要確定這5000程式沒受影響 那改起來就是災難 自然而然很不想去亂動 或者動不動就想重寫 用公司變大去解釋或許可以讓人理解 公司變大了要有不同部門 可以把部門的小變動固定在某個部門內 不會去影響全公司 當然微服務要弄起來也要有一些成本 所以小公司才校長兼撞鐘 -- ※ 發信站: 批踢踢實業坊(ptt-site.org.tw), 來自: 1.170.183.199 (臺灣) ※ 文章網址: https://ptt-site.org.tw/Soft_Job/M.1699539414.A.6D2

→ MoonCode: 別 11/09 22:52

→ tsao1211: 你用過微服務？ 11/09 23:46

→ a12838910: 好奇 台灣的公司 用微服務的多嗎… 11/10 00:27

噓 tzouandy2818: 冗言贅字太多 11/10 01:22

推 abccbaandy: 2023了還在吹微服務，面試都很少提這東西了 11/10 01:28

推 laetuon: 到底要多有錢才會想包養 11/10 01:28

噓 qwer338859: 沒那屁股別吃那瀉藥 11/10 01:35

推 yamiodymel: 看得出來你大概也知道微服務有多雷 11/10 03:06

推 mozume: 會有原原po問題的千萬別用微服務，連單體服務都搞不好的 11/10 06:05

→ mozume: 上微服務只會是災難 11/10 06:05

推 DrTech: 不管是服務還是微服務，你的概念就是模組化把解偶合，減少 11/10 08:10

推 slot365: 閨蜜上包養網還推薦我... 11/10 08:10

→ DrTech: 每次變更需要處理的工作量而已。 重點是人的頭腦有沒有這 11/10 08:10

→ DrTech: 種概念：沒有這種工作概念，不管你是用什麼服務，微服務， 11/10 08:10

→ DrTech: 還是把自己搞死。 11/10 08:10

→ DrTech: 這就是為什麼，有些人覺得：怎麼可能專案完成越多，事情與 11/10 08:12

→ DrTech: 壓力越多。有些人覺得，專案完成越多，事情越多的差異。不 11/10 08:12

推 colortea: 包養? 11/10 08:12

→ DrTech: 同的人，做事情的觀念決定了一切。 11/10 08:12

推 devilkool: 我只寫過服務而已，原來微服務過氣了嗎 11/10 09:12

推 lazarus1121: 微服務我覺得只有server掛掉有差 11/10 09:26

→ lazarus1121: 其他還是看開發習慣吧 11/10 09:26

噓 WTS2accuracy: 微服務大部分都是拿來嘴砲的 會用的少之又少 11/10 09:39

推 glenber: 現在包養網都這麼直接嗎 11/10 09:39

→ WTS2accuracy: 多的是沒多少成效甚至比不拆還慘 11/10 09:40

→ WTS2accuracy: 別網路文章看一看就高潮吹上天 實際沒這麼簡單 11/10 09:42

推 sniper2824: 差低 11/10 10:16

推 happy8649: 推原po，講得很好 11/10 11:15

→ happy8649: 感覺很多人只是沒遇過微服務>單體的狀況 11/10 11:15

推 Kimbel: 歐美包養真的很平常嗎? 11/10 11:15

→ happy8649: 或是沒在成熟的微服務體系待過而已 11/10 11:15

→ happy8649: 微服務在處理的並不只是程式的問題 11/10 11:15

→ happy8649: 但可能大部分台灣公司的業務大小就是不會需要微服務吧 11/10 11:17

→ mirror0227: 微服務不就是你原本只要管一個服務 拆開之後變成要管 11/10 11:31

→ mirror0227: 10個微服務 11/10 11:31

推 tale1890: 男友上包養網 該放生嗎 11/10 11:31

推 srwhite: 我們公司拆完之後發現外部耦合變得有點嚴重XD 11/10 11:35

→ srwhite: 想改api都不確定會不會哪裡有別支呼叫 11/10 11:35

→ srwhite: 不過應該是可以從文件管理層面解決 11/10 11:36

推 tsaigi: 說微服務是嘴炮的 應該是忘了加”在台灣” 這個條件 11/10 12:20

推 hegemon: 樓上, Amazon影音串流那邊都寫文章說把微服務換回單體反 11/10 12:22

推 waterway: 是這個包養平台嗎 11/10 12:22

→ hegemon: 而省很多錢了 11/10 12:22

→ airtsubasa: 微服務用在機台單一方面還可以啦 因為改動不大 通常也 11/10 13:07

→ airtsubasa: 只會丟資料收資料 11/10 13:07

推 abccbaandy: 上面那個管10個微服務的，代表跟本不需要拆 11/10 13:09

推 Litfal: 根本問題還是內聚力和粒度阿 11/10 15:31

推 mark1888: 交男友跟包養有什麼差別 11/10 15:31

推 jason222333: 推 11/10 15:43

→ WTS2accuracy: 微服務跟單體是權衡取捨 無腦推的根本實際經驗吧 11/10 17:26

→ WTS2accuracy: *沒實際經驗 11/10 17:27

推 shvanta: 推 11/10 17:28

→ viper9709: 推DrTech 11/10 17:51

推 Quaranta: 包養網到底在紅什麼? 11/10 17:51

推 dan114021: 微服務如果亂切或是沒有搞懂系統未來的走勢很容易 11/10 18:42

→ dan114021: 陷入微服務架構的缺點，微服務有些優點沒被提到， 11/10 18:42

→ dan114021: 實作的語言執行的系統都不需要考量其他服務。當然 11/10 18:42

→ dan114021: 在小公司或是一個人負責一堆微服務的時候會覺得用 11/10 18:42

→ dan114021: 單體的方式開發比較快，比起開API給其他微服務呼叫 11/10 18:42

推 schlemm: 有人被包養嗎 11/10 18:42

→ dan114021: ，單體內call function在開發上快多了 11/10 18:42

推 yamagishi: 軟體就是會成長，不可能避免的 11/10 20:24

→ yamagishi: 不要亂就像你說的不能每一個人都有相同的存取權限 11/10 20:24

→ yamagishi: 所以才有部門這種東西做為權限的最小單位 11/10 20:24

推 yamagishi: 你後面補充的DDD那些就一種管理方式 11/10 20:28

推 Wirol: 求包養...管飽就好XD 11/10 20:28

→ yamagishi: 對於一些team來說合適，有些不合適 11/10 20:28

→ yamagishi: 跟review還有人員教育比起來，更偏重文化的部分 11/10 20:28

→ yamagishi: 你這邊的舉例可以說是相當不合適 11/10 20:28

推 happy8649: DDD放在這裡不會不適合吧？DDD很大部分就是在探討doma 11/10 21:19

→ happy8649: in boundary/bounded context的拆分 11/10 21:19

推 marecht: 阿姨!我不想努力了(求包養) 11/10 21:19

→ happy8649: 再說它不只是一種管理方式，它是一種軟體工程中的設計 11/10 21:19

→ happy8649: 方式 11/10 21:19

→ TSMCfabXX: 「任何部門有任何變動都要想辦法去確定這5000人都確定 11/10 22:12

→ TSMCfabXX: 這個變動」不用啊, 製造部最大, 他說了算 11/10 22:12

→ brucetu: 感覺你以為劃分了部門就不會亂 11/11 12:51

推 riokio: 有沒有富二代要包養我 11/11 12:51

→ brucetu: 你再去看一次原篇第一段提出的問題，根本不是任何開發方 11/11 12:52

→ brucetu: 法可以解決的 11/11 12:52

→ brucetu: 給你一套神級開發方法，你就能一人扛整個公司的全部系統 11/11 12:53

→ brucetu: 開發加維運嗎 11/11 12:53

→ brucetu: 整篇我只看到紙上談兵吹微服務好處，無視微服務本身的開 11/11 12:56

推 wiimas: 身邊有朋友被包養嗎 11/11 12:56

→ brucetu: 發成本，你真的用過？ 11/11 12:56

→ brucetu: 這種吹觀念實際上對讀者沒幫助的文章網路上一堆 11/11 12:57

→ brucetu: 跟推廣企業引入大數據就可以怎樣怎樣，沒什麼差別 11/11 12:58

→ brucetu: 有聽過自從引入微服務，公司裁了幾個工程師節省成本的？ 11/11 13:01

→ brucetu: 應該都是成本反而更高 11/11 13:01

推 Branlli: 亞洲最大包養平台上線了 11/11 13:01

推 jack0204: 有哪個開發流程是為了節省成本的? 11/11 14:38

噓 L90156: .......一群井蛙，沒實作過微服務的，不懂真的可以閉嘴!! 11/11 15:46

→ L90156: 偶然看到這版，進來看一下，思維水準都太低端了... 11/11 15:47

→ alihue: 樓上不要只會嘴，發一篇有水準的來看看啊 11/11 16:35

推 s06yji3: 他一定不會發的啊（攤手） 11/11 20:10

推 Cinedt: 這個包養網正妹好多 是真的嗎 11/11 20:10

推 GinginDenSha: 有人在說Amazon那篇文章，那篇根本上是因為要反覆在 11/12 12:39

→ GinginDenSha: workflow framework 中不同step 重複存取object sto 11/12 12:39

→ GinginDenSha: rage 的資料，所以可能耗費多餘的IO跟cost，但重點 11/12 12:39

→ GinginDenSha: 還是想清楚step 的切分、工具及情境的使用，並不是 11/12 12:39

→ GinginDenSha: 說一定monolithic 就一定好。 11/12 12:39

推 Drither: 真的有這麼多人在找包養嗎 11/12 12:39

噓 hegemon: 不管選擇走哪條路都要先想清楚需求跟人力呀，不是像很多 11/12 13:33

→ hegemon: 人那樣無腦微服務. 每個場景都有各自適用的方法 11/12 13:33

推 fullout: 推概念解說 11/13 22:04

→ alan3100: DDD是切分方式不是管理辦法 講引入微服務成本更高多半是 11/14 02:48

→ alan3100: 沒devops 沒自動化後面維運管理爆炸 11/14 02:49

推 Notker: 有人可以分析一下包養平台的差異嗎 11/14 02:49

→ alan3100: 開發流程不為了成本是為了啥? 隕石開發就好啦 11/14 02:52

推 drakd4d: 微服務大多只是解決政治問題而已 11/14 19:19

→ drakd4d: 成本很高的 11/14 19:20

→ gpctv: 77樓，很兇喔！ 11/15 15:02

推 MIM23: 微服務後還要用APIM控管API，事情會越來越多 11/17 22:10

推 Peycere: 那個包養網人最多XD 11/17 22:10