微服務面臨的挑戰，微服務的發展挑戰分析？

微服務的發展挑戰分析？

1樓：雲南嘉薈教育

對於大多數的程式設計開發公司來說，微服務的出現可以說給軟體程式設計開發行業帶來了新的變化和發展趨勢，下面我們就一起來了解一下關於微服務程式設計開發目前都有哪些挑戰。

隨著團隊在這個持續演化的軟體生命週期環境中不斷地探索，他們所在組織的一些獨特方面——他們個人的集體體驗和特定的專案需求——正塑造著這個演化旅程，也就是說，並非每一條神旦洞通向雲原生的道路都是相同的。應用程式和團隊將利用其中一種或一些甚至是全部方法開啟走向雲原生的道路。

在這裡，我們將專注於微服務。並非所有嘗試建立微服務的應用程式或團隊(從頭開始或拆解單體)都能夠真正意識到微服務架構的好處。通常，由於應用程式設計要求具備前所未有的監控和管理水平，團隊一般都未能取得顯著成功。

從建立能夠支援分散式系統問題的環境和基礎設施，到組織和培訓團隊、培養文化和制定運營實踐，再到應用可觀察性和基礎設施即**，以及融入現代devops監控工具，團隊的一次微服務體驗可能是非常混亂的。然而，一旦形成了持續交付的穩定節奏，它們的好處(例如交付速度)卻是其他企業架構應用程式所無法比擬的。

微服務可以幫助團隊實現更快的交付和迭代。微服務為獨立的服務開發團隊帶來語言和技術選擇的民主化——團隊一邊迭代和持續交付軟體(通常作為服遲滾務)，一邊快速地建立新功能。作為一種設計可擴充套件、可獨立交付的服務的雲原生方法，微服務讓團隊可以以佳的方式確定服務需求的優先順序。

這種提供鬆散耦合功能的做法推動了敏捷性和迭代交付，並強制實現它們所暴露的api的「契約義務」。

來自各個方面的挑戰。

由於每個微服務都遊枯需要對外暴露api，微服務行為的一致性和版本控制方案的一致性就成了部署微服務時需要面臨的兩大挑戰。大量的微服務不僅加劇了在一致的環境中建立功能、注入devops文化和實踐的挑戰，還加劇了確保多個新服務具備互操作性的挑戰。部署的微服務越多，這些挑戰就越嚴峻。

在部署微服務時，更多的移動部件和額外的服務增加了監控的難度。想象一下：你有乙個由五個服務組成的應用程式，每個服務又由大約10個容器組成。

你對應用程式的物理拓撲及其服務間的邏輯互動的瞭解很快就會過時，因為它的元件會移動。電腦培訓建議與傳統監控工具支援的靜態虛擬機器不同，微服務的監控工具需要支援臨時構造和原生服務發現。如果你正在使用過時的監控工具，無異於在蒙著眼睛走鋼絲。

微服務架構帶來的變化分析？

2樓：北大青鳥志遠科技

微服務架構對於程式設計師來說是需要掌握的新型技術之一，而其受到追捧的原因就是符合網際網絡的發展以及其便捷性。今天我們就一起來了解一下，微服務架構帶來的變化。

微服務架構給it系統和團隊帶來了以下顯著的變化：

基礎設施的公升級，需要引入虛擬化(如docker)，現存基礎設施也需要與之進行適配；

系統架構的公升級，需要引入服務註冊(如敗昌consul)，服務間的互動方式也需要與之進行適配；

運維平臺的公升級，建議引入日誌收集(如fluentd)，分散式跟蹤(如zipkin)和儀表盤(如vizceral/grafana)等；

運維效率和自動化水平的提公升也迫在眉睫，否則無法應對例項數量，變察轎扒更頻率，系統複雜度的快速增長；

觀念的轉變，基礎設施，系統架構和運維平臺等的大幅公升級，猶如小公尺加步槍換成飛機大炮，相應的戰略戰術也需要與之相適配才行。

微服務架構下使用者面臨的監控問題。

在轉型到微服務架構以後，使用者在監控方面主要會面臨以下問題。

監控配置的維護成本增加。某個**系統大概有106個模組，每個模組都需要新增埠監控，程序監控，日誌監控和自定義監控；不同服務的監控指標，聚合指標，報警閾值，報警依賴，報警接收人，策略級別，處理預案和備註說明也不完全相同；如此多的內容，如何確保是否有效，是否生效，是否完整無遺漏。

當前針對維護成本，業界常用的幾種方法有：

通過變數的方式儘量減少人工輸入；

通過監控配置檔案解析做一些可標準化的校驗；

通過故障演練驗證報警是否符合預期；

其次，三方依賴越來越多。霍營電腦培訓發現例如docker的可靠性很帆豎大程度上取決於宿主機，如果所在的宿主機發生資源爭用，網路異常，硬體故障，修改核心引數，作業系統補丁公升級等，都可能會讓docker莫名其妙地中招。