為了瞭解微服務的當前和未來狀態，我們採訪了來自21個組織的25名IT主管。與早期採用的技術一致，我們的問題的答案是多樣的。我們問他們:“您認為影響微服務的創建和管理的最常見問題是什麼?”下面是他們告訴我們的:
Data
如果你不正確地劃分責任，你就會遇到問題。將任何應用程序應用到分佈式系統中。想想你可能會遇到的問題。管理數據和管理狀態是許多人在管理有狀態和無狀態數據時遇到問題的地方。考慮事件驅動的命令和數據通信，以構建最好的體系結構。
1)狀態管理和組件定義。如果崩潰和燒傷，您可以替換它，如果它是無狀態的。
2)關注架構。如何拆分不同的組件。你可以增加複雜性而不是減少複雜性。
複雜性
任何考慮的團隊都不應該介入，如果他們不清楚他們試圖解決的問題的領域。微服務帶來了大量的開銷。隨著時間的推移，它會得到回報，因為你有更多的組件。從一開始，一切都與開銷有關。在確定自己需要微服務之前，避免使用微服務。當您為採用的每種語言選擇堆棧、語言和數據庫時，您需要開發樣板代碼和編制管理。如果您願意為it生產做好準備，請仔細考慮。最終與數據的一致性也是如此。簡單是最基本的事情要記住。簡潔明瞭的api和邏輯，很容易讓你的頭腦去構建更復雜的應用程序和行為。
大多數傳統組織都不得不移動傳統的應用程序。這是一個多年的旅程。你不能停止支持單體系統。一次只做一次服務。您需要一個平臺來運行這個整體並從中挖掘出功能。我們的目標是成為一個在邊緣運行微服務的平臺。我們使用一個虛擬機監控程序將一個整體搬到VM上，知道相同的平臺可以支持Docker和VM。k8不太適合逐步過渡。
容器的一個問題是構建容器映像和發佈到存儲庫的複雜性。這是一個開發人員過去並不擔心的問題。微服務更難調試和故障排除。有這麼多的微服務，很多移動部件。對單個微服務進行故障排除的能力並不像對傳統的單片應用程序進行故障排除那麼容易。您不能直接訪問微服務。可能有很多複製品。對於開發人員來說，這是一個陡峭的學習曲線。
監控
三種類型:
1)對他們正在構建的系統的可見性和可觀察性的渴望。當您希望系統在開發和生產中處於開箱即用狀態時，能夠使系統透明;
2)更大的企業和工程組織的遷移有強烈的願望去理解最佳實踐，需要更多的關於如何到達那裡，陷阱和焦慮-標準化在哪裡可以，在記錄成功和失敗的一邊;
3)工程師的異花授粉——工程師們在工作，他們不得不絞盡腦汁，從零開始建造已經建成的東西。需要供應商和開源領導者對市場進行更多的教育。更多關於如何做事情的文檔。
在不合適的時候嘗試做微服務。我們如何讓自動化和可觀察性到位?我們如何測試我們的應用程序並獲取數據以詢問平臺和應用程序，以及何時比較它們何時開始退化?可見性和向對應用程序開發人員負責的人公開。
2018年7月，我們調查了354名受訪者，詢問我們的用戶在使用微服務架構時遇到了哪些挑戰。對跨多個微服務的端到端流程缺乏可見性:59%的受訪者。不明確的錯誤處理，導致在微服務之間的邊界上出現未處理的錯誤:50%的應答者。從事不同微服務的團隊之間的跨團隊溝通:46%的受訪者。使用不同的編程語言/使用不同的數據存儲編寫的複雜支持服務:38%。僱傭擁有合適技能的開發人員有困難:35%。由於大量服務導致的安全問題:30%。這些問題既有技術性的，也有組織性的。為了獲得跨多個微服務的長時間運行流的可見性，並以自動化的方式處理錯誤，確保流在啟動後總是結束，還不存在合適的工具。團隊仍在研究如何在新的組織結構中有效地進行溝通，並試圖找到具有微服務體系結構經驗的合適人選。
技能
大多數人不理解將服務構建為細粒度的，並將其作為單個應用程序一起使用的重要性。當您將ESB(企業服務總線)分解為多個服務時，會遇到一系列挑戰。主要的挑戰是建立服務之間的通信並使其具有彈性。保證交付作為所選代碼的一部分實現。您必須考慮如何使用分散的數據管理來管理數據。如何創建數據組合。通過整個網絡支付的自主服務的總體監控和可觀察性。需要使用觀察工具。跟蹤標準。如果你沒有一個平臺，你的企業文化也沒有很好地結合起來，你就很難將微服務融入到產品中。無論你追求的是什麼新項目，你都要把它作為一個微服務來做，而不是改變傳統的應用程序。慢慢開始，逐步進入架構。
在構建、交付和管理微服務方面，存在很大的技能差距。很少有開發人員具備理解領域、從數據到API的服務編碼、理解總體體系結構、與CI/CD管道集成以及交付運行中的服務所需的技能。用於低代碼微服務創建和簡化管理的工具對“ok”開發人員來說是一個巨大的提升，使他們在很少培訓的情況下安全地提高速度，同時將“好的”開發人員變成搖滾明星。
安全
Discovery（發現）是最重要的。如何從安全角度發現微服務。它經歷了所有你期望它經歷的治理。編目微服務和高級api。創建微服務是一種商品。看看谷歌，“在10分鐘內創建一個微服務的10個步驟”。
1)如果沒有適當的治理，利用一個公開不應該公開的數據的服務，就可能變成蠻荒的西部。
2)數據安全。
3)發現管理。Swagger被認為有助於微服務管理。
其他
接口是什麼?確保您沒有破壞依賴關係。有哪些服務，以及如何訪問它們?Kubernetes (K8s)和Istio都有幫助。要找到人們正在尋找的答案並不容易。不確定該問什麼問題來解決這個問題。太早期階段。
與IBM和Pivotal合作伙伴的客戶不會直接看到問題。凱捷諮詢公司和埃森哲公司在重組和架構方面看到了商機。企業在經歷變革的過程中，建立了大量的支持結構。創造軟件的藝術和科學。瞭解具有數字功能的軟件如何增強您的產品以提供更好的體驗。
最大的問題是溝通和所有權，因為一切都按照自己的計劃進行。自動化將是下一個。如果沒有自動化，如果你很難部署大的東西部署成百上千的小的東西如果沒有自動化就無法完成。在分解系統之前，把自動化放在適當的位置。
我認為影響微服務的最大問題將是維護API兼容性。api成為一種“單向”契約。一旦它們被釋放，它們可能需要無限期地得到支持，因為組織內外的任何人都可以使用它們。
服務註冊和發現。
閱讀更多 程序你好 的文章
