云原生時代的微服務，適合所有人么？

作者：云科技時代雜志 2019-10-17 14:07:43

開發(fā)

架構

新聞

云原生 微服務是一種優(yōu)化資源的體系結構方法，這些資源為復雜、快速、分布式基礎設施上的大規(guī)模服務和軟件提供計算、存儲和網(wǎng)絡。大多數(shù)有IT歷史的組織，傳統(tǒng)上都是在虛擬技術棧上構建軟件，這些技術棧由操作團隊手動維護。

成都創(chuàng)新互聯(lián)公司是專業(yè)的涪城網(wǎng)站建設公司，涪城接單;提供網(wǎng)站建設、網(wǎng)站制作,網(wǎng)頁設計,網(wǎng)站設計,建網(wǎng)站,PHP網(wǎng)站建設等專業(yè)做網(wǎng)站服務;采用PHP框架,可快速的進行涪城網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團隊,希望更多企業(yè)前來合作!

 微服務是一種優(yōu)化資源的體系結構方法，這些資源為復雜、快速、分布式基礎設施上的大規(guī)模服務和軟件提供計算、存儲和網(wǎng)絡。大多數(shù)有IT歷史的組織，傳統(tǒng)上都是在虛擬技術棧上構建軟件，這些技術棧由操作團隊手動維護。今天，開發(fā)人員大規(guī)模使用云服務來構建應用程序架構和自動化工作負載。面向機器架構的時代正在過去——面向應用程序的基礎設施正在流行。今天，這些資源提供了全堆棧的、開發(fā)人員構建應用程序體系結構所需的內(nèi)容。開發(fā)團隊需要為應用程序架構更全面地開放資源，這證明了DevOps工具在功能強大的分布式架構上運行的深層需求。

對技術工具、服務和平臺的需求包含在構成微服務的內(nèi)容。無限的計算、網(wǎng)絡和存儲資源的平衡，為運行任意數(shù)量的服務提供了機會和障礙。就像任何一種過度興奮的、吸引技術社區(qū)注意的新方法一樣，在圍繞微服務的炒作中，往往沒有提及復雜性。從表面上看，開發(fā)、部署和管理軟件的完美方法可能要比最初出現(xiàn)的方法復雜得多。因此這是一個讓公司深入了解業(yè)務目標、團隊開發(fā)、工作流和用于構建應用程序架構的服務的旅程。通常，對于那些技術背景與微服務的現(xiàn)代方法不匹配的人來說，做出改變并不容易。微服務要求組織重新考慮運行其業(yè)務的現(xiàn)有軟件體系結構，以及組織如何適應需要新的技術技能和文化轉變來匹配的實踐。這種實踐有風險，并不是每個人都能做到。

盡管如此，大約90%的開發(fā)人員至少都在為一些工作負載考慮微服務架構。然而，當被更具體地問及它們在生產(chǎn)應用程序中的使用時，這個數(shù)字下降了。然而，與任何快速發(fā)展的新興技術一樣，要想理清所有的炒作，就要理解微服務如何實際應用于日常工作。這有助于從微服務的實際基礎開始，然后權衡軟件體系結構本身的好處和缺點。

微服務的定義

微服務是一種基于將應用程序構建為小型服務集合的軟件開發(fā)體系結構方法。對于構成“小型服務”的代碼量并沒有標準定義。一些專家說，這與查詢服務運行狀況時的“大小”有關。如果一個服務需要多個team來管理，那么它就太大了。每個服務都有自己獨特且定義明確的角色，在自己的流程中運行，并通過HTTP應用程序編程接口(API)或消息傳遞進行通信。每個微服務都可以獨立于應用程序中的所有兄弟服務進行部署、升級、擴展和重新啟動。它們通常由自動化系統(tǒng)編排，使實時應用程序的頻繁更新成為可能，而不會影響最終用戶。

個人可能更習慣使用應用程序的概念。但如今，一般的企業(yè)組織至少使用十幾種不同的軟件產(chǎn)品和集成。記錄業(yè)務開銷、進度跟蹤和工資管理等，是組織現(xiàn)在使用運行在云服務上應用程序的幾個例子。使用緊湊而專業(yè)的工具以提供優(yōu)雅用戶體驗的方式完成每項工作是有意義的，類似于個人應用程序在社交網(wǎng)絡上發(fā)布照片、視頻和與他人聯(lián)系時所獲得的體驗。微服務使用包含云服務的分布式體系結構，以一種松耦合的模式組合在一起來進行擴展。就像樂高積木一樣，微服務中的組件可以在適當?shù)奈恢脴嫿ㄒ粋€統(tǒng)一的模型。

(微服務是小型、獨立擴展和管理的服務。每個服務有其自己獨特和良好定義的角色，運行自己的流程和通過HTTP API以或Messaging進行溝通)

首先，開發(fā)人員確定構建項目所需的獨立服務“部分”，例如搜索、身份驗證、消息傳遞和銷售處理。然后，從服務、庫和可用代碼片段、從開源到交鑰匙企業(yè)解決方案的大雜燴中進行選擇，并將所有內(nèi)容整合到一個功能應用程序中。

云原生浪潮

云原生微服務的概念源于容器體系結構的發(fā)展。

在基于容器的體系結構之前，開發(fā)人員需要構建技術堆棧，然后將其部署到云服務或健壯的企業(yè)體系結構上。這些應用程序是面向機器的，并使用監(jiān)控軟件及其在云服務和企業(yè)上的性能的一系列工具進行優(yōu)化。這是超越面向服務架構(SOA)的一步，盡管有些人認為SOA只是由供應商重新命名以銷售相關產(chǎn)品的微服務，這是有一定道理的。

微服務可以被認為是SOA的一種類型。容器只是使方法更加廣泛可用，并降低了SOA帶來的風險程度。在虛擬機(VM)上運行的SOA需要時間和投資來構建、部署和運行。VM運行在操作系統(tǒng)上，而操作系統(tǒng)也必須進行移植才能在SOA環(huán)境中運行。這是一項繁重的手工工作，并且?guī)缀鯖]有為尋找實際運行SOA本身的好的方式而承擔風險的空間。

由docker領頭，容器改變了游戲規(guī)則。Docker代表了SOA的發(fā)展和平臺即服務(PaaS)的時代。Docker通過其簡單、易用和低風險推動了采用率。它將Linux容器技術打包成開發(fā)人員可以訪問和使用的內(nèi)容。構建、運行和管理容器技術只需很少的開銷——這與重量級的SOA世界形成了鮮明的對比，后者需要大量的投入，尤其是在網(wǎng)絡和存儲方面。

容器現(xiàn)在充當微服務的底層基礎，通過API網(wǎng)關和gRPC等新方法連接?？傮w而言，容器使SOA可以通過簡單地使技術更易于使用而大規(guī)模實施，所涉及的風險遠遠低于以往。微服務與DevOps、持續(xù)集成和持續(xù)交付(CI / CD)，以及容器的使用密切相關。事實上，“微服務”和“容器”這兩個術語經(jīng)常一起使用。但是，容器和微服務并不是一回事。微服務可以在容器內(nèi)運行，但它也可以作為完全配置的虛擬機運行。也就是說，基于容器和開源的平臺，如Docker和Kubernetes，是開發(fā)、部署和管理微服務的一種非常有效的方法。容器空間中已經(jīng)存在許多成熟且健壯的工具、平臺和其他服務，這使得容器化非常適合基于微服務的應用程序。

雖然容器和微服務獨立存在并且用于不同的目的，但它們經(jīng)常一起使用;它們甚至還被視為DevOps的好拍檔。容器是微服務的一種使能技術，這也是微服務通常在一個或多個容器中交付的原因。由于容器是隔離環(huán)境，因此無論用于創(chuàng)建每個微服務的編碼語言如何，它們都可用于快速安全地部署微服務。一旦基于微服務的應用程序達到顯著的規(guī)模，在沒有容器的情況下幾乎不可能管理它。運行在集群編排平臺(如Kubernetes或Mesos)之上的容器化微服務，包括在云中、本地或混合模式，是當前對向外擴展的云原生應用程序的定義。

重要的是要注意雖然容器是將代碼打包到微服務中的“嚴格”方式，但也可以將整個單體應用程序打包到容器中，而不需要創(chuàng)建微服務。隨著云計算的進一步發(fā)展，以及更多組織從傳統(tǒng)基礎架構中解放出來和/或開始評估無服務器架構的用例，打包可以而且很可能會發(fā)生變化。事實上，許多微服務的支持者表示，它們只是多云和無服務器計算的跳板，這是一種利用資源自動化功能和填補應用程序架構空白的新興方法。

有行業(yè)專家認為，將微服務和容器結合起來只是一個實施細節(jié)，而不是一個重要的抽象概念，除非在VM上有很多需要遷移到同一技術堆棧的傳統(tǒng)應用程序。

微服務的好處

通過使小型自治團隊能夠獨立開發(fā)，部署和擴展各自的服務，微服務基本上可以并行化開發(fā) ——從而以指數(shù)方式加速生產(chǎn)周期。這種敏捷性是大型企業(yè)在多種報告中指出采用微服務所引用的首要原因，其次是改進的可擴展性。

微服務可以讓開發(fā)人員不必浪費時間重新解決已經(jīng)解決的技術問題。持續(xù)集成和部署基本上構建在微服務架構中。微服務可以直接把很多基礎設施風險帶出項目。隨著基礎設施變得幾乎不可見，微服務團隊可以進行通常以小時周期運行的快速迭代，從而持續(xù)降低錯誤功能的風險，同時增加價值。

換句話說，使用微服務，團隊中的每個開發(fā)人員都可以忘記底層基礎設施，專注于自己的項目。然后在生產(chǎn)中，如果單個項目模塊不能完全正確地工作在一起，那么很容易對它們進行隔離、拆卸和重新配置，直到正確地工作為止。這些組件是松耦合的，就像樂高一樣。這種方式提供了使用可互換的部件在應用程序體系結構中大規(guī)模運行的能力。它們的獨立和獨立結構也帶來了安全性優(yōu)勢，因為更容易通過自動化和實施安全策略的現(xiàn)代安全平臺進行控制。

隨著組織的發(fā)展，工程團隊可以更輕松地擴展和維持速度。微服務架構的主要好處不是技術，而在于團隊開發(fā)和人員管理。相比之下，當代碼庫增長到一定規(guī)模時，單體應用程序變得無法適應和管理。管理這種規(guī)模的應用程序架構的團隊絕不能讓單體架構失效。如果整體架構失效了，那么業(yè)務也會隨之流失。因此編寫腳本以防止應用程序泄漏并在主要版本升級之間構建各種補丁成為企業(yè)架構師的重要優(yōu)先事項。功能是預先定義好的，并按照優(yōu)先級與整體相適應;客戶則被夾在中間，并且做出的強制性決策可能是短期的解決方法，但會帶來較長期的問題，例如定制化的腳本隨著時間推移而失效，并且依賴于具有企業(yè)基礎架構記憶的人員。這本身是一個糟糕的體驗，因為新的軟件升級可能無法解決客戶遇到的問題。

一個主要問題是(單體)應用程序會變得極其復雜。它太大了，任何單個開發(fā)人員都無法完全理解。因此修復bug和正確實現(xiàn)新特性將變得困難且費時。更重要的是，這是一個惡性循環(huán)。如果代碼庫難以理解，那么將無法正確進行更改。許多組織已經(jīng)達到了這樣一個階段，即管理單體應用整體結構的痛苦超過了采用新的微服務方法。微服務的采用是這類組織的優(yōu)秀選擇，盡管它也有自己的挑戰(zhàn)。

微服務的缺點

微服務是經(jīng)典單體應用的對立面，具有明顯的優(yōu)勢。但是，與任何正在發(fā)展的技術一樣，早期采用曲線可能很陡峭。目前，Netflix和PayPal等大公司最有效地采用了這種方法，由于強大的內(nèi)部資源和工程團隊，這些公司已經(jīng)能夠轉向微服務架構。

Netlify首席執(zhí)行官兼聯(lián)合創(chuàng)始人Mathias Biilmann表示:“當你擁有一個非常龐大、資源豐富的企業(yè)，個人團隊能夠管理每項服務并確?？芍赜眯院涂商剿餍詴r，這是非常棒的?！比欢?，對于其他人來說，痛苦是真實存在的。根據(jù)有關報告，只有1%的企業(yè)使用微服務表示他們對架構沒有任何挑戰(zhàn)。操作開銷、日志記錄和監(jiān)視方面的挑戰(zhàn)以及缺乏技能被列為最主要的挑戰(zhàn)。離開單一的應用程序體系結構意味著失去將所有部分粘合在一起的固定工作流。最常見的情況是，因為IT團隊主要負責集成和維護許多不同服務的基礎設施，采用微服務體系結構會增加操作成本。團隊必須在微服務遠景與實際需要之間艱難地找到平衡，才能使其發(fā)揮作用并取得成功。

當將整體分解為微服務時，將冒著一個非常分散的系統(tǒng)風險，開發(fā)人員需要花費大量的時間和精力將服務和工具粘合在一起，并且缺乏可以跨項目工作的常見模式和平臺 。為了真正利用微服務，需要能夠構建可以實現(xiàn)一鍵設置的“膠水”供應商?！?/p>

(遷移到微服務，通常為帶來了大量運維挑戰(zhàn)，因為集成和維護很多不同服務的基礎設施責任落在了IT團隊)

LAMP堆棧的出現(xiàn)可以作為一個很好的對比。Linux、Apache web服務器、MySQL和 PHP等免費工具為web開發(fā)開辟了新的可能性。但當公司圍繞WordPress、Drupal和Joomla等項目構建集成工具時，LAMP體系結構才真正起飛。

在真正的微服務方法中，團隊只運行他們需要的小服務，而不運行其它任何負載。但是，這種實施和編配工作已經(jīng)超出了許多中小型組織的工程范圍。將一個整體分割成許多更小的、獨立的服務在速度和敏捷性方面有許多優(yōu)勢，但也有許多挑戰(zhàn)。微服務架構可以增加支持和維護的運營開銷，因為每個服務都有自己的語言和要求。這也使得監(jiān)控和安全性變得更加復雜，因此需要更高水平的自動化和工具。而且由于服務之間的通信現(xiàn)在通過網(wǎng)絡進行，因此它會對服務發(fā)現(xiàn)、消息傳遞、緩存和容錯產(chǎn)生新的要求，這些要求可能會給系統(tǒng)帶來壓力，如果處理不當可能會導致性能問題。雖然Service Mesh解決了許多這樣的問題，但是引入一個沒有流量管理的Service Mesh服務，它自己就會產(chǎn)生一些問題，這些問題可能會導致更嚴重的性能問題。

可以提前做所有想做的測試，并且這會對要發(fā)布的代碼相當有信心。但是當真正把它投入生產(chǎn)時，就會遇到各種各樣的問題，因為實際上并不知道代碼在生產(chǎn)中會如何表現(xiàn)。流量管理實際上是將部署與發(fā)布解耦。部署是指擁有新代碼、新版本并將其投入生產(chǎn)，但還不占用任何客戶流量?？梢宰鰺熿F測試、內(nèi)部測試，這些測試都在生產(chǎn)中運行。當發(fā)布一個版本時，就會開始思考：要給這個新版本的代碼帶來什么樣的流量?如果有能力把流量控制到非常精細的水平的話，可以分割、控制、并逐步推出新的代碼更改。

沒有工程資源或技能將穩(wěn)定的基礎架構與現(xiàn)有的開源代碼和工具結合在一起的組織，很難 讓微服務的好處大于挑戰(zhàn)。操作和性能問題也可能困擾那些沒有就其服務(依賴關系和版本兼容性)進行溝通的團隊，并且必須在生產(chǎn)失敗時撤回已經(jīng)寫入的代碼。幸運的是，微服務市場正在起飛。許多公司現(xiàn)在不僅生產(chǎn)微服務本身，還生產(chǎn)無縫連接它們所需的平臺、工具和框架。

微服務不適合所有人

分布式服務的基礎架構已經(jīng)成熟，但是更高的效率只能來自于更好的聲明式系統(tǒng)，這些聲明式系統(tǒng)來自于改進的自動化技術和改進的可觀察性。因為沒有任何微服務是完全相同的，這么做可能很棘手。它們的任何自定義工作流程就像雪花一樣。不同之處在于底層的體系結構，以及如何適應針對不同工作負載的微服務方法的不斷開發(fā)。

設置邊界很重要，這樣微服務就不會被認為是萬靈藥或有趣項目的分支，因為微服務需要更多的管理。開發(fā)者大批量地構建微服務要追溯回2014年至2016年的鼎盛時期，這些開發(fā)者在喝茶聊天的時候決定了新的微服務該怎么構建。因此現(xiàn)在如果有幾十個團隊決定創(chuàng)建自己的微服務，會發(fā)生什么?雖然管理是完全可能的，但是會犧牲效率，從而影響優(yōu)化和獲得更好性能的過程。

毫無疑問，微服務是有效的。但是，一個構建良好的單體應用整體架構也可以擴展，并且在許多場景中仍然是很好的選擇。例如，運行相同服務或工作程序的多個實例不一定需要微服務。創(chuàng)建不可伸縮的微服務也是完全可能的。因此在確定解決方案之前，首先考慮面臨的問題是很重要的。

就基礎設施和技術支持而言，生態(tài)體系現(xiàn)已接近關鍵的規(guī)模。微服務正迅速成為DevOps工具包中的一個工具，從而更好、更深入地利用資源。這進而創(chuàng)建了新的空間來交付額外的服務，從而進一步實現(xiàn)聲明性的和優(yōu)雅的工作流、工具和平臺的潛力。

向著微服務過渡的業(yè)務和流程決策

云原生微服務是一種真正令人興奮的架構演化，尤其是在構建、部署和管理復雜分布式應 用程序方面。然而，大多數(shù)圍繞微服務的討論直接涉及到技術：持續(xù)集成和部署、容器、 編排器等等。雖然技術實現(xiàn)很重要，但是還有一些更重要的事情需要考慮。

微服務必須與組織的目標相適應。開發(fā)人員可以構建微服務，但是體系結構只有與業(yè)務目標相結合時才有價值。因此必須提出關鍵問題，從業(yè)務用例、現(xiàn)有團隊、技能和職責開始——采用微服務的決策取決于組織的目標和遠景。組織中具有實現(xiàn)復雜體系結構經(jīng)驗的人員必須提出一個重要的問題，并在繼續(xù)前進之前得到答案：我們是否適合微服務體系結構?

Container Solutions的CEO和聯(lián)合創(chuàng)始人Jamie Dobson曾表示，客戶找過來希望使用微服務作為技術問題的解決方案，實際上卻常常是組織問題的技術解決方案。

評估云原生服務。評估企業(yè)采用云原生微服務與企業(yè)本身的關系，而與企業(yè)的規(guī)模、行業(yè)甚至實際技術關系不大。首先，從決策到執(zhí)行的微服務遷移應該由企業(yè)的組織和管理方式驅(qū)動：

商業(yè)模式：軟件可以差異化業(yè)務嗎?如果是這樣，開發(fā)團隊必須繼續(xù)增長和擴展，因為組織需要更多的資源和服務功能。基于微服務的體系結構允許更快的迭代開發(fā)，可以在跨多個團隊的工作流中使用。依賴專有的、統(tǒng)一解決方案的組織將不太適合微服務方法。系統(tǒng)記錄管理(ERP)到服務級別協(xié)議(SLA)類的商業(yè)軟件協(xié)議意味著，如果企業(yè)選擇遵循將它們帶入微服務討論的路徑，那么它們將發(fā)生根本性的轉變。對于完全依賴于商業(yè)軟件平臺的組織來說，實現(xiàn)微服務的成本可能會更高。微服務所需的在敏捷性和可伸縮性方面的工程支持和開銷成本將超過它們的價值。

文化和內(nèi)部流程：微服務需要一套新的工具和流程，并打破舊的工具和流程。對于負責管理單體的組織來說，突然改變工作流可能是一個困難的轉變。接受DevOps原則是微服務成功的關鍵。然而，舉例來說，團隊可能會抗拒從傳統(tǒng)的瀑布方法轉向敏捷方法。微軟首席云開發(fā)布道師Bridget Kromhout曾表示，“如果你意識到所涉及的人有著他們自己的習慣而且他們也許在不遠的未來就要退休了，那么這種抵制并不是完全不合理的，而且他們不喜歡一切改變的想法，他們只是以他們喜歡的方式看待問題?！?/p>

微服務的基本復雜性在于應用程序體系結構本身：根據(jù)體系結構，每個服務都需要自己的支持團隊、工具和基礎設施。并不是每家公司都在正確的位置采取行動。專家強調(diào)，并不是說錯誤地采用這種體系結構是不可能的，只是這個過程會更長或更復雜。對于許多有著錯誤商業(yè)動機或文化的組織來說，成本將高于收益。Bridget Kromhout再次強調(diào)：不能通過實施正確的技術解決方案來解決組織中的每一個問題，因為組織是復雜的系統(tǒng)，其中也有可能以不可預知方式行事的人。

那么，什么時候微服務不適合企業(yè)呢?

敏感行業(yè)：某些行業(yè)，例如金融服務和醫(yī)療保健，面臨法律、報告和合規(guī)要求，需要與新技術相協(xié)調(diào)。可追溯性因素：與更年輕、更緊湊或更敏捷的組織相比，一家在商業(yè)領域經(jīng)營數(shù)十年的全球性公司，尤其是平均員工保留時間超過10年的公司，很可能更難適應向全新架構的巨變。“停滯不前”的公司：這些是規(guī)避風險的公司，決策鏈很長，層次結構僵化。因此當采用一種新的響應性微服務范例時，這些組織并不十分適合，甚至可能會對所需的快速適應產(chǎn)生抵觸。

New Relic的首席站點可靠性工程師Jonathan Owens表示，考慮轉向容器和微服務架構的組織應該問自己以下問題：您的運營團隊向開發(fā)人員提供了什么產(chǎn)品，該產(chǎn)品使用了什么抽象層? 該產(chǎn)品是否適合您的業(yè)務，還是容器更合適? 容器是否更好，以至于您愿意更改抽象層，從而更改運營團隊提供的整個產(chǎn)品，以便使用它們?您是否已準備好創(chuàng)建新角色來管理此新抽象的規(guī)模和可靠性?

沒有哪個組織會在一夜之間發(fā)生這樣的變化。從一個理想化的新架構到第一個產(chǎn)品部署的過程需要改變許多想法并創(chuàng)建新的流程，這并不總是很有趣。尋找具有微服務專業(yè)知識且能夠做出必要的工具和架構決策的工程師也很困難。這些專家包括難以捉摸的“全棧開發(fā)人員”，他們了解每一層的應用程序：從網(wǎng)絡和托管環(huán)境，到數(shù)據(jù)建模、業(yè)務邏輯、API和用戶界面以及用戶體驗(UI / UX)。這些人處于獨特的位置，可以看到技術體系結構和組織是如何相互關聯(lián)的。要實現(xiàn)成功的微服務轉換，組織需要一個按比例構建的技術體系結構，但維護該結構的團隊也同樣重要。

這就是為什么許多正在向微服務過渡的組織選擇與專業(yè)服務公司合作，這些公司專門幫助客戶使用各種不同的架構來構建云原生應用程序。這些顧問可以幫助評估組織對微服務的需求和適用性，或指導他們采用更合適的替代方案。

微服務最適合嗎?

對于由業(yè)務原因而采用微服務的組織，可以滿懷信心地帶領團隊轉型。領導項目的團隊在組織中具有重要地位，并可以開始設置適合現(xiàn)有工作流的優(yōu)秀實踐。團隊可以采用服務來推動應用程序體系結構的整體開發(fā)，并為組織使用更多資源運行微服務做好準備。

做準備時需要技巧和人員管理。適合開發(fā)團隊的服務將定義微服務。團隊的目標是使微服務成為一個建立在其價值基礎上的“底座”，并不斷優(yōu)化開發(fā)人員的體驗。

評估應用程序的職責是定義微服務應用程序組件的第一步，Netlify首席技術官David Calavera曾表示，他是Docker和GitHub先前工作的微服務老手。確定應用程序職責的相互依賴關系，這關系到微服務的結構。Connascence是一個評估應用程序組件和互連的衡量標準。因為兩個或多個組件是并發(fā)的，所以如果改變其中一個組件，還必須更改另一個組件。

考慮到這種關系，可以更好地評估是否值得擁有不同的微服務，或者是否應該保留的單體架構。除了相互依賴之外，團隊必須牢記將這些組件分離到微服務中會引入它們之間的網(wǎng)絡連接——這不可避免地增加了系統(tǒng)的復雜性。

應用程序體系結構開發(fā)是個人和團隊如何就他們自己以及重疊的編排進行交互和通信的直接結果。很明顯在這一點上，像Kubernetes這樣的架構正變得越來越重要。隨著越來越多的開發(fā)人員添加進來，應用程序變得越來越復雜，體系結構的總體復雜性也隨之增加。但是正如所看到的，這些應用程序架構并不適合所有人。

Calavera警告說:“您不希望以犧牲理想架構為代價來增加不必要的復雜性。”

分享題目：云原生時代的微服務，適合所有人么？
文章鏈接：http://www.fisionsoft.com.cn/article/dhiecho.html