[請益] 中台架構常見嗎

看板Soft_Job作者 (系館守護神)時間5月前 (2023/12/05 06:21), 4月前編輯推噓19(19推 0噓 60→)
留言79則, 27人參與, 4月前最新討論串1/3 (看更多)
前輩們大家好，小弟目前工作將滿五年，但不算實習的話其實只在兩間公司工作過，一是工研院一是歐洲支付公司，所以對於一些東西在業界到底常不常見蠻多時候都不太確定 剛看到前面一篇郵局的文，裡面提到前台中台後台的架構，讓我想到一直很想問的中台架構 中台一詞我好像都只有在中文的資源比較常看到，除了郵局那篇，像是之前板上有出現過PTT official app的go-openbbsmiddleware repo裡的簡報也有提到中台架構，加上之前換工作時朋友幫內推的金融公司也有提到中台 但在英文的資源就比較少看到 感覺有點像N-tier architecture，又有點不太像 我有查到一篇我覺得把中台架構的前世今生講得蠻清楚的中國文章 "你需要的不是中台，而是一名合格的架构师"(https://ppt.cc/fEtyox)，也有跟我近期最好的朋友chatgpt討論了一下，感覺這架構很有意思 我後來比較熟悉的架構是microservice architecture，我現在待的公司也是用這個架構為主，所以我一直以為它就是現在主流的架構XD 我今天下班前問我一個比我資深一些的俄羅斯同事，他也沒聽說過中台架構，該不會他跟我一樣菜(? 想跟前輩們請教一下，請問中台架構常見嗎? 還是只有在中國跟台灣的業界比較常見? 如果只有中國跟台灣比較常見的話，那是為何會有這種文化差異呢? 有前輩可以經驗分享一下嗎 如果是中台架構的經驗談也很棒! 第一次發文有點緊張 還請各位前輩多多包涵 ----- Sent from JPTT on my Google Pixel 5. -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 217.103.7.251 (荷蘭) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1701728495.A.CC2.html
推
12/05 07:14, 4月前 , 1F
這問題真的問得很好，也點出了N-tier architecture，又有
12/05 07:14, 1F
→
12/05 07:14, 4月前 , 2F
點不太像
12/05 07:14, 2F
→
12/05 07:17, 4月前 , 3F
你可以去了解，阿里文化。阿里文化常見名詞。"中台"是他們
12/05 07:17, 3F
→
12/05 07:17, 4月前 , 4F
提出來的，其實類似技術概念很多，但中國互聯網太競爭，每
12/05 07:17, 4F
→
12/05 07:17, 4月前 , 5F
年必須要換個名詞，概念，一點點改善，就要搞的世界第一的
12/05 07:17, 5F
→
12/05 07:17, 4月前 , 6F
創新，部門才有績效。導致於這些名詞文化。
12/05 07:17, 6F
→
12/05 07:20, 4月前 , 7F
阿里文化又是中國互聯網文化的輸出根源之一，台灣又很愛炒
12/05 07:20, 7F
→
12/05 07:20, 4月前 , 8F
中國的專有名詞，導致於這種現象。
12/05 07:20, 8F
→
12/05 07:21, 4月前 , 9F
中國人發明的，當然非中國的國家就沒相關名詞了。
12/05 07:21, 9F
是偶像Dr大!!! 原來還有非技術層面的考量 好我去查一下 感覺很有趣
推
12/05 07:25, 4月前 , 10F
似乎只有金融業在使用這名詞
12/05 07:25, 10F
→
12/05 07:43, 4月前 , 11F
以我所知中台是阿里流行到中國業界，因為中文的關係
12/05 07:43, 11F
→
12/05 07:43, 4月前 , 12F
所以部分台灣公司也會講
12/05 07:43, 12F
→
12/05 07:44, 4月前 , 13F
但歐美目前主流還是應該還是 DDD
12/05 07:44, 13F
推
12/05 08:30, 4月前 , 14F
中台跟DDD應該不能放在一起比吧？一個系統架構，一個程式
12/05 08:30, 14F
→
12/05 08:30, 4月前 , 15F
架構
12/05 08:30, 15F
→
12/05 08:32, 4月前 , 16F
以我不多的經驗 感覺中台就是個沒那麼微的微服務
12/05 08:32, 16F
推
12/05 08:35, 4月前 , 17F
可以去看看阿里支持中台到現在不支持的相關文章
12/05 08:35, 17F
→
12/05 08:39, 4月前 , 18F
然後在一些技術研討會上，金融業的演講就會看到這類架
12/05 08:39, 18F
好酷 聽起來金融業真的是相當用比較多中台的產業
→
12/05 08:39, 4月前 , 19F
構
12/05 08:39, 19F
推
12/05 08:52, 4月前 , 20F
中台架構成本很高 不管是管理上、開發上或維護上 通
12/05 08:52, 20F
→
12/05 08:52, 4月前 , 21F
常是多個前台服務商業邏輯相同的部分抽出變成一個中
12/05 08:52, 21F
→
12/05 08:52, 4月前 , 22F
台服務元件 然後大家共用 但如果前台各自為政或每個
12/05 08:52, 22F
→
12/05 08:52, 4月前 , 23F
在業務邏輯上都有部分差異時 共用元件本身就會變很
12/05 08:52, 23F
→
12/05 08:52, 4月前 , 24F
複雜 而且負責中台的團隊很容易變成被推工作的對象
12/05 08:52, 24F
→
12/05 08:52, 4月前 , 25F
什麼垃圾都可以說：放中台，以後可以共用
12/05 08:52, 25F
很有畫面XD 真的很好奇中台實務上跑起來會是什麼體驗，感覺管理不好真的一不小心大中台就會變得很恐怖
→
12/05 09:22, 4月前 , 26F
就只是幫 N-tier 取了另一個名詞，用來吹
12/05 09:22, 26F
→
12/05 09:24, 4月前 , 27F
本來共用的東西就可以抽出來獨立，你想想 CGI 跟 cache s
12/05 09:24, 27F
→
12/05 09:24, 4月前 , 28F
erver 還有 database engine 和 檔案系統之間的互動關係
12/05 09:24, 28F
→
12/05 09:26, 4月前 , 29F
為什麼不要每支應用實作自己的 cache server 要抽一個單
12/05 09:26, 29F
→
12/05 09:26, 4月前 , 30F
獨的 cache server 出來？ 那我可不可以說 cache server
12/05 09:26, 30F
→
12/05 09:26, 4月前 , 31F
是中台？ 如果你說不行他只是工具，那我前面掛一層API隨
12/05 09:26, 31F
→
12/05 09:26, 4月前 , 32F
便包一點商業邏輯進去算不算中台？
12/05 09:26, 32F
→
12/05 09:28, 4月前 , 33F
然後我們部門就有一個中台了 績效++ ，其實軟體工程本來
12/05 09:28, 33F
→
12/05 09:28, 4月前 , 34F
就是在各種粒度上把程式之間的關係切割乾淨，有什麼好吹
12/05 09:28, 34F
→
12/05 09:28, 4月前 , 35F
前中後的，很無聊
12/05 09:28, 35F
→
12/05 09:30, 4月前 , 36F
你把後端 micro service 和前端 app 依據業務性質分成前
12/05 09:30, 36F
→
12/05 09:30, 4月前 , 37F
中後三種分類一樣可以跟長官說你們有中台
12/05 09:30, 37F
這樣講也是有理XD 但他們這樣搞應該有對應的組織架構，team之間的合作應該有他們的一套玩法 chatgpt是跟我說跟N-tier主要差異是中台把業務層面也放進來，不只是技術層面
→
12/05 11:48, 4月前 , 38F
隨便找個不是對user也不是管理介面的東西叫中台就是中台了
12/05 11:48, 38F
→
12/05 11:50, 4月前 , 39F
台灣的某些業界就只是這樣用的，不是真的什麼架構
12/05 11:50, 39F
原來有些公司是這樣嗎XD 好我以後有遇到會記得
→
12/05 12:03, 4月前 , 40F
去中台的話題都退流行了，糾結技術名詞沒啥意義，看本
12/05 12:03, 40F
→
12/05 12:03, 4月前 , 41F
質而不是什麼中台微服務DDD，每個公司案子狀況都不同，
12/05 12:03, 41F
→
12/05 12:03, 4月前 , 42F
偷懶的人才會想用一個概念套所有，就像是想著跑了敏捷
12/05 12:03, 42F
→
12/05 12:03, 4月前 , 43F
後管理就會變好一樣
12/05 12:03, 43F
推
12/05 12:23, 4月前 , 44F
中台對應的英文是platform team嗎？
12/05 12:23, 44F
我也查不太到，chatgpt說是middle platform
→
12/05 12:24, 4月前 , 45F
用來維護一些相似領域但不同應用的共用系統
12/05 12:24, 45F
推
12/05 12:40, 4月前 , 46F
middleware? 這個英文應該叫什麼
12/05 12:40, 46F
推
12/05 12:57, 4月前 , 47F
Platform不是平台嗎？他比後端還底層吧
12/05 12:57, 47F
推
12/05 13:22, 4月前 , 48F
中台是從大陸來的吧 淘寶天貓等等的複雜電商架構
12/05 13:22, 48F
推
12/05 13:24, 4月前 , 49F
對岸的名詞，看看就好，他們很會吹的
12/05 13:24, 49F
推
12/05 13:39, 4月前 , 50F
阿里都在去中台化了還有人在吹
12/05 13:39, 50F
※ 編輯: Burwei (31.161.147.222 荷蘭), 12/05/2023 17:31:22 ※ 編輯: Burwei (31.161.147.222 荷蘭), 12/05/2023 17:33:10
推
12/05 17:33, 4月前 , 51F
對岸Web仔比台灣強沒什麼毛病啊
12/05 17:33, 51F
→
12/05 17:34, 4月前 , 52F
台灣一堆連Nginx Redis MySQL都用不好的公司
12/05 17:34, 52F
→
12/05 17:35, 4月前 , 53F
整天吹系統設計、DDD、微服務、水平擴展
12/05 17:35, 53F
→
12/05 17:35, 4月前 , 54F
這才最可悲
12/05 17:35, 54F
→
12/05 18:56, 4月前 , 55F
問題很簡單 規模不夠大的都不會有這些問題
12/05 18:56, 55F
→
12/05 18:58, 4月前 , 56F
中台應該是data middle platform直譯過來的
12/05 18:58, 56F
→
12/05 19:02, 4月前 , 57F
data mesh/fabric/lake 我覺得你可以找自己適用的情景
12/05 19:02, 57F
我查的時候也在想是不是因為中國公司很大，所以才發展出這種架構 但念頭一轉美國公司也很大也沒聽說有這種東西(也可能只是我沒聽說) 可能跟前面前輩說的一樣有一些非技術層面的考量 ※ 編輯: Burwei (31.161.147.222 荷蘭), 12/05/2023 19:19:17 ※ 編輯: Burwei (31.161.147.222 荷蘭), 12/05/2023 20:06:59 ※ 編輯: Burwei (31.161.147.222 荷蘭), 12/05/2023 20:08:46 ※ 編輯: Burwei (31.161.147.222 荷蘭), 12/05/2023 20:09:50
→
12/05 20:26, 4月前 , 58F
在台灣大概只有講銀行比較常聽到中台
12/05 20:26, 58F
※ 編輯: Burwei (31.161.147.222 荷蘭), 12/05/2023 20:28:48
→
12/05 20:58, 4月前 , 59F
中國技術翻譯遠超繁體 找對文章有時候比啃原文好懂很多
12/05 20:58, 59F
推
12/05 21:58, 4月前 , 60F
郵局、銀行最喜歡的架構：敏前台、大中台、穩後台
12/05 21:58, 60F
→
12/05 23:11, 4月前 , 61F
這就是低平台專屬的中間件 這樣來看資料庫都算中台
12/05 23:11, 61F
→
12/05 23:12, 4月前 , 62F
這又搞了一個新名詞...
12/05 23:12, 62F
推
12/06 06:21, 4月前 , 63F
十幾年前券商就很多間有搞中台的了
12/06 06:21, 63F
推
12/06 10:39, 4月前 , 64F
二十多年前做投信投顧系統時，交易員那稱作前台，帳務會
12/06 10:39, 64F
→
12/06 10:39, 4月前 , 65F
計稱作後台，中台是做風控的，個人覺得以名詞來說算常見
12/06 10:39, 65F
→
12/06 13:22, 4月前 , 66F
這篇在講的就不是風控中台 是在= =
12/06 13:22, 66F
→
12/06 13:30, 4月前 , 67F
名詞聽聽就好 這幾年流行微服務 那些請來的講師就都
12/06 13:30, 67F
→
12/06 13:30, 4月前 , 68F
講一樣的口號 什麼敏前台厚中台 哪有這麼多人力來維
12/06 13:30, 68F
→
12/06 13:30, 4月前 , 69F
護
12/06 13:30, 69F
→
12/06 13:57, 4月前 , 70F
畢竟講師是靠嘴賺錢不是負責debug
12/06 13:57, 70F
→
12/06 13:58, 4月前 , 71F
沒有用拿同樣的需求開發兩套系統 你也很難客觀量化新提出
12/06 13:58, 71F
→
12/06 13:58, 4月前 , 72F
的架構有多少好處
12/06 13:58, 72F
→
12/06 13:59, 4月前 , 73F
隨便你喊節省幾%成本都行
12/06 13:59, 73F
推
12/06 16:58, 4月前 , 74F
中國的資料庫會用到分庫分表，就需要用中台轉換SQL語句
12/06 16:58, 74F
→
12/06 16:58, 4月前 , 75F
吧
12/06 16:58, 75F
推
12/06 17:47, 4月前 , 76F
這問題基本上就是看各公司的商業模式跟架構而已家大業大
12/06 17:47, 76F
→
12/06 17:47, 4月前 , 77F
用這種模式沒什麼不好啊
12/06 17:47, 77F
推
12/07 07:29, 4月前 , 78F
BFF那類的吧? 分拆複雜需求在不同服務橫向溝通用的吧?
12/07 07:29, 78F
推
12/08 23:31, 4月前 , 79F
中台=提供某種業務領域/技術領域/資料領域的服務
12/08 23:31, 79F
‣ 更多 Burwei 的文章
文章代碼(AID): #1bRb3lp2 (Soft_Job)
‣ 更多 Burwei 的文章
文章代碼(AID): #1bRb3lp2 (Soft_Job)