1樓：退火
中颱和微服務這是兩碼事
他們有聯絡，但是完全不一樣，區別很大，有人說是炒冷飯說明他不懂微服務、中臺
粗略的理解為
中颱是業務的一種，是業務本身，其作用是以某業務願景為需求，進行業務能力的彙總、重組
微服務是業務執行的一種形式，是業務執行的載體，其主要作用是可以輕量、高可用的執行業務本身
防槓警告
當然還有其他的作用存在，但是不夠核心，不展開
2樓：
簡單回答下這個問題。
要回答這個問題，我們首先還是要看下中颱和微服務這兩個概念是針對什麼來說的。
中臺：說中颱一定會說到前台，原來是中台前臺不分，現在是拆分為中颱和前台。
微服務：說微服務一定說單體應用，原來應用粒度太大，要垂直拆為更小的微服務。
這個搞清楚後，我們就更加容易理解兩個概念的區別，即：
中颱更多的是指橫向拆分，即共性業務能力的下沉，然後再將服務能力開放給前台應用使用。而微服務強調的是大單體要拆分和進一步解耦。
而我們現在構建企業中臺，基本是中颱和微服務都會使用到，即既需要進行橫向拆分，共性能力下沉。同時對於下沉的共性能力又需要按微服務思想進一步拆分多個微服務模組。在中颱思想裡面更加強調了共性能力下沉和能力開放，能力開放以微服務裡面常見的輕量API介面方式進行。
了解了這個我們看區別就比較清楚了，具體如下：
中颱的構建不一定要採用微服務，及時中臺就是乙個系統，只要滿足共性業務能力下沉，那麼也滿足中颱的要求。類似我們傳統架構裡面的MDM主資料系統，按現在微服務思想應該拆分多個服務，但是即使沒拆，我們仍然可以理解為是企業中臺建設思路。
不至中颱構建可以用微服務，對於前台應用構建同樣可以採用微服務。對於一些大的前台應用如果不能復用，那麼也需要拆分為多個微服務進行解耦。
中臺強調橫向拆分，微服務強調縱向拆分。
中臺強調能力開放，微服務不強調共性能力開放，但是提供API閘道器工具進行能力開放。
中臺裡面還含了資料中臺，資料中臺構建本身就不能按微服務思路做。
3樓：
中颱是一種思想，架構，微服務是中颱架構的一種技術實現，可以不叫微服務技術，使用介面對接也可以實現，或者WebService技術也可以，Restful技術也可以實現
4樓：傅飛
這兩個概念根本就不是同乙個層級的，中颱是整體，微服務是個體，中颱的建設有兩個過程：沉澱和開放。
1、沉澱是將各業務系統的公共功能（例如使用者管理、支付管理、產品管理等）識別出來，並做成乙個個模組放到中臺，這些模組可以由微服務實現；
2、開放是將這些微服務的API對外開放，讓上層業務系統可以隨意呼叫。中颱的公共功能越多，上層業務系統的開發將變得越簡單，做厚中颱、做輕應用。
本質上中颱是沉澱和開放公共功能的地方，可以叫中颱，也可以叫平台，沒有發明中臺這個概念之前，也是由各種平台來承載這些公共功能。
5樓：有木聊科技
中颱是商業概念，微服務是技術概念。
前者範圍更廣，涉及公司組織架構，團隊管理，技術形態，更適合商業宣傳，受眾是各大公司高層；
後者其實是技術概念，受眾是技術人員。
6樓：Eason
非技術。
個人理解，中颱偏強調標準化管理——通過中臺，對外暴漏的API（資料或業務）進行標準化管理；微服務偏向強調服務組織方式，新冠前按省管，新冠時按村管；
7樓：新興IT民工
不管是中颱也好，微服務也好，都是針對於對複雜問題的拆分。而設計中對複雜問題的拆分，其實本質上都是一致的：那就是模組化，而模組之間的拆分指導原則就是高內聚，低耦合。
個人理解，中颱和微服務都是針對這一原則給的指導性的落地方案。當然，在兩種方案中，都還有不同層次的，有業務上的，有技術層面上的。。。但是本質上我覺得都是對複雜問題去做模組化，並且達到業務要求。
對於乙個業務系統，最理想的方式就是將業務系統打造成樂高積木一樣的元件，我們搭建乙個業務系統就可以拿著乙個乙個的樂高積木搭就可以了。在實際設計和開發過程當中，因為各種因素的限制，會對積木的粒度做一定程度的判斷，這可能就是中臺，微服務中的單個元件的考慮了。最近的DDD也是指導設計人員去做這個考慮的原則吧。
8樓：xu ciro
中颱和微服務本質上應該屬於不同種類的任務，解決的問題不同。所以說這兩者談不上關係更講不出區別。
先說微服務，微服務是為了應對業務需求變化快而產生的一種架構思路。
想象個實際場景吧，前端版本乙個個的往外發，後台服務往往需要適配多個前端版本，如果前後端業務緊耦合，後台服務會為了適配歷史版本會變的異常複雜。因此後台服務解構為微服務；如果微服務提供的是「能力」，那麼採用的實踐叫做soa；如果微服務提供的是「資源」，那麼採用的實踐叫做restful。以後無論業務需求如何變化，後台服務「能力」、「資源」是穩定的。
因此，微服務是工程中總結出的一種最佳實踐。
再說中臺，中颱火的時間不長。中臺解決的並非技術問題，而是企業發展中的暴露出的管理問題。
這些年網際網路在中國飛速發展，各廠的業務線增長的非常快。不論是kpi，這兩年在推的okr，都沒辦法解決業務間協調的問題。業務線業務資料無法打通，業務上各部門基礎設施喜歡自己造輪子、技術棧不相容。
業務資料不打通，大資料做不起來，所以業務發展都會受阻；在基礎設施上重複投資也是導致大量的資源浪費。
因此，中臺這個概念就是乙個披著技術外衣的管理工具。
9樓：蔣震宇
這個問題不需要長篇累牘。
微服務是SOA的一種形式。
滿足以下兩點之一的SOA架構即可稱為中臺：
1.有跨系統復用能力的，比如電商的訂單中心2.可協調前後臺研發節奏的，比如解決保險業務的移動化快迭代與核心系統穩定封閉之間矛盾的系統
10樓：noflycat
IT界有個不好的習慣，那就是喜歡炒概念。本來挺簡單的東西喜歡說得很複雜。
做單位it專案也六七年了，與東軟、華為等不少公司交流過，發現很多所謂新東西都是從舊東西演化過來的，微服務、中颱也是如此。
不嚴謹的大概說下…
最早的程式是單體、單伺服器，最多有本機程序間通訊。後來想綜合利用不同服務程式的能力，就提出了SOA，簡單粗暴就是通過網路呼叫服務。這個理念其實一直沒有過時，現在的微服務不過是其延伸而已。
因為SOA並沒有限制提供服務的後端到底是「巨」還是「微」。而中颱只是微服務模式下的一種組織方式而已。
具體如下:
微服務是把很多不同的功能拆分到多個服務提供者，而不是集中在乙個單體服務提供者上。好處很多，可擴充套件性強，不易單點故障等。而拆分方式主要包括按業務拆分和按IT功能拆分。
按業務拆分:以票務系統為例，就是把查票、訂票、支付等業務分開部署，每個微服務都可能有web服務、資料庫、檔案儲存、文件處理等模組。麻雀雖小，五臟俱全，而且每只麻雀五臟可以完全不一樣。
這種模式靈活性高，但對開發運維要求高（有多複雜，可以自己想想），適合大團隊 ，人力資源充足的單位。
按IT功能拆分:把通用的、常用的功能做成微服務，供所有應用呼叫，如檔案儲存、文件處理、郵件、身份認證、許可權管理、資料分析等，所有應用都用同一套。中臺大致就是這種模式，為上層業務應用提供服務，當然，只要常用，某些業務服務也可能下沉為中颱的一部分。
這種模式適合小團隊，盡量集中統一，維護開發成本低。
其實，我們單位幾年前的IT建設規劃就已經是類似阿里巴巴的中颱那樣的了，只是我們不會吹概念。並沒有覺得中颱有什麼太新鮮的東西。
用什麼模式，根據單位實際來吧。別被某些概念帶偏了。
我向上面申請的上千萬的應用平台專案就是自己設計的，類似中臺模式的，如果今年批下來，這兩年就有得忙了
11樓：
中臺由於業務的複雜性，需要微服務這樣架構才能實現。
中颱從技術層面來說，需要統一的U業務高階I元件，提高介面統一性然後需要API閘道器，這樣才能把資料整合介面上，再後需要微服務接入API閘道器，這樣才能這麼多業務整合一起
12樓：
你到高校去，導師承包乙個專案，分給學生做，學生根據甲方需求，沒日沒夜做好乙個專案，做完畢業，然後師弟過來接手，一看傻眼了，完全看不懂，推倒重做，接著畢業，接著讓小小師弟接手，小小師弟接著崩潰，接著推倒重做。
組裡唯一日益增長的，是導師的荷包，手下無數的橫向專案ppt，還有組裡某個學生才能看得懂的專案成果。這些拆分無比稀碎，功能又交疊極大的微型工程，只有做這個業務的學生看得懂，其它學生想用，費勁，沒門。
導師一看，不成呀，每次招乙個苦力過來，都要高年紀的學生帶，越帶越吃力，還重複造輪子，出活越來越慢，成本越來越高。
咋辦呢，導師心裡一橫，把幾個技術好的高年級博士叫過來，畫了乙個大餅，說你們前途無亮，讓他們把整個組的專案都整和梳理一遍，把裡面共同，且通用的東西都抽離出來，做了沉澱，讓以後新來的師弟能夠快速完成橫向專案。
這幾位博士不負眾望，高質量地完成了導師的任務，讓新來師弟調包溜得飛起，小小小師弟很快地解決了導師的橫向專案，迅速畢業，走向人生巔峰。
而這幾位博士，卻因為沒有直接完成導師的橫向專案，被導師延期了。。。
13樓：張木
個人覺得，二者的區別還是在解決不同問題之上：中臺，解決如何快速開發乙個新的系統的問題，這是公司高層關注的問題。微服務：
解決快速修改、測試、交付，以及團隊規模過大之後的高效協作的問題，這是架構師、團隊負責人層面的問題。類似使用者登入、訂單、支付、第三方服務（如簡訊通知、快遞查詢）等通用功能，都可以抽出來做成中臺；而一般我們微服務的實踐過程中，也會抽出使用者登入、訂單、支付、第三方服務（如簡訊通知、快遞查詢）作為基礎服務，給各個應用使用--這東西實際上就是通用功能。所以在我們開發者看來，中颱和微服務中的基礎服務是乙個東西，確實，開發叫做中臺或者微服務中的基礎服務，我們還是幹一樣的活兒。
14樓：
某單位客服，真的很擔心單位研發中心未來的微服務化，解決個問題要轉無數個產品線，誇張的一次流轉到了日誌儲存過期還沒找到問題點，扯皮扯的一塌糊塗。。。
15樓：北風之神
我對中颱的理解是降低公司成本，類似的現在共享服務，共享單車汽車什麼的。
我對微服務的理解也是降低公司成本，減少維護成本，讓每個人都有事幹，做自己的一塊，而不是東拼西湊，增加溝通。
總的來說，就是降成本的玩意。
作為乙個程式設計師，操心這些幹啥，如果微服務和中颱能讓你掙的錢更多，那當我放屁。
不管是中颱還是微服務還不是壓榨程式設計師的？？
幹了微服務和中颱你頭髮就不會掉了？腰不會困了？老婆不會跑了？
閒的蛋疼
伺服器集群和一台伺服器有什麼區別？
泰海 美玲 出現任何故障，如 硬碟 記憶體 CPU 主機板 I O板以及電源故障，執行在這台伺服器上的應用就會切換到其它的伺服器上。集群系統可解決軟體系統問題，我們知道，在計算機系統中，使用者所使用的是應用程式和資料，而應用系統執行在作業系統之上，作業系統又執行在伺服器上。這樣，只要應用系統 作業系...
雲服務和雲計算有什麼區別？
天冕科技 從概念上來講，雲計算是指一種技術架構，主要包含了虛擬化 自動化部署 分布式計算等技術，這個技術架構的優點是可以對外表現非常優秀的平行計算效能 規模伸縮性和健壯性。而雲服務是指在雲計算的技術架構支撐下，對外提供的按需分配 可計量的IT服務，可用於替代使用者本地自建的IT服務。從應用上來講，站...
雲主機和雲伺服器有什麼區別呢？
可以認為是同乙個概念，各家公有雲會根據自己的習慣或者IDC領域公認的定義習慣來定義，但是如果你發生了把公共定義來認識某家公有雲廠商產品的情況，最好還是要看看這家廠商文件裡是怎麼解釋的。畢竟觀念公認的定義，並不代表某家廠商就會接受這種定義，而且很多廠商的高層的出身背景也不一樣，比如有些是來自國外的，國...