微服務是一種軟件架構策略,有利于改善整體性能和可擴展性。你可能會想,我的團隊需不需要采用微服務,設計微服務架構有哪些原則?本文會給你一些靈感。
文章速覽:
微服務設計的要素
微服務架構設計的5個原則
微服務是一種軟件架構策略,將應用程序分解為一組解耦的、自治的服務。這些獨立的應用服務通過API相互通信。每個服務都由其專業領域的專家團隊管理,以便每個軟件開發團隊可以控制自己的開發周期,按照自己的時間表進行測試和部署,使用自己的企業工具和資源,加速上線時間。為了評估你的團隊是否需要采用微服務架構。這里有一些值得深入討論的細節。
一、微服務設計的要素
設計微服務架構的第一步是形勢評估。開發者網站總結的十大微服務設計原則之一是單一責任原則,即每個服務只需要將其所有資源投入到微服務應用程序的一個功能中。
1.通過領域驅動設計實施微服務
軟件架構師需要進行領域分析,以確定如何劃分每個服務以及需要將哪些元素納入應用堆棧中。這種領域分析被稱為領域驅動設計(Domain Driven Design, DDD)。它將實體模式和聚合模式等模式應用到單個限界上下文(bounded context)中,以便以更高的計算精度來識別單個域的邊界。
總之,應該圍繞特定的業務功能構建每個微服務。一旦確定了領域并了解了它們的邊界,就可以定義最適合應用堆棧的變量了。
2.選擇技術棧
創建微服務技術棧較為特別。通常你需要使用各種工具、框架和編程語言,將它們整合成一個耦合的系統。在選擇工具時考慮以下變量:
編程語言
選擇用于微服務的最佳編程語言,取決于你最熟悉哪種語言、可用于所需功能的庫以及每種語言提供的功能套件。顯然,選擇你的開發團隊已經大范圍使用的語言可以節省時間和精力。
根據2021年JetBrains關于微服務的調查,“用于微服務開發的三種最流行的語言是Java(41%)、JavaScript(37%)和Python(25%)”。這些流行的編程語言都有大量的在線開發者支持、成功應用開發的示例、運行環境,比如Node.JS,以及豐富的客戶端庫。
總之,確保所選的語言適合當前業務問題。例如,Python在數據分析中很受歡迎,而JavaScript是全棧開發的最優選擇。
數據庫
在為微服務架構構建的應用程序選擇適合的數據庫時,應將可伸縮性、可用性和安全性置于首要位置。選擇一個最能支持你在微服務中計劃使用的數據模型的數據庫。你的技術棧應該能夠處理任何應用負載,確保使用故障切換協議可用性,并保護應用免受惡意攻擊。
通信
你的業務功能可能需要您的微服務使用同步的服務間通信方法執行某些操作,對于其他操作,可能需要使用異步通信。可以使用多種通信格式和協議來輔助微服務通信,包括HTTP/REST、gRPC和AMQP。
對于異步通信,使用支持消費者組的事件驅動消息代理可以提高可伸縮性和可靠性,確保應用程序能夠擴展,而不會導致任何服務無法訪問的情況。
監控
每個微服務團隊都負責監視應用程序性能,通常使用日志記錄和可觀察性工具來跟蹤操作。這使得開發人員和運維人員可以跟蹤整個系統,如應用程序性能、消息代理流與數據庫資源利用率。
在使用消息代理時,考慮使用一個日志流,其中每個微服務都可以發布消息。這樣,您可以將首選的日志記錄和可觀察性工具連接到流,并在不減慢應用程序的情況下異步監視您的應用程序。
二、微服務架構設計的5個原則
那么,如何確保你的微服務架構可以發揮最佳作用?以下是五個微服務應用程序設計原則,可供你參考。
1.低耦合和高內聚
低耦合和高內聚可以通過前面提到的單一責任原則來解釋。賦予每個領域團隊單一的職責,有助于加強該領域內的內聚,使得該服務內的所有功能都在某種程度上緊密耦合。每個服務都由其自己的領域專家和工具管理,但仍然可以通過API和其他協議相互通信。這有點像來自不同部門的同事如何互動:當有助于完成工作時,大家彼此分享信息,而不會過多地談論與他人無關的細節。
2.適應性
業務應用程序很少是靜止不變的。隨著新的業務需求的出現,行業的假設發生變化,技術能力提供更多功能,軟件也會發生變化。微服務應該具有可適應性,以滿足新需求出現時可以進行適應。世界在變化,人們在變化,所以軟件也應該變化。
3.基礎設施自動化
實現微服務的一個原因是它們能夠自動化流程,從而提高整體可擴展性。借助 Kubernetes 等容器編排系統,您可以使用單個鏡像與微服務一起部署微服務的整個數據庫。在Kubernetes控制器的幫助下,這些可移植性優勢可以幫助DevOps團隊管理、調度和編排自動容器部署。
4.離散邊界
實施微服務要求在任何給定應用程序中的服務都要維護自己的分散數據。服務邊界應該將與任何單個服務相關的所有邏輯和數據與應用程序中的其他服務隔離開。
這也是允許容器化微服務進行獨立部署的邏輯。這個原則也有一些反對者,他們認為這會導致數據冗余激增。但建立這些明確的邊界最大的好處之一是:當一個微服務承載自己的數據時,任何奇怪的行為都被限制在微服務內部。
5.為故障而設計
干擾是經常發生的,應用服務會在毫無征兆的情況下癱瘓。例如,挖掘機開挖光纜中斷網絡操作,人們會忘記續訂域名,系統會因防火墻故障引起的數據連接問題而中斷等。所以,需要盡力考慮潛在的故障的可實施對策。設計具有彈性的解決方案,比如使用斷路器模式,以防止當某個微服務無法執行給定操作時其他服務中斷。
-
軟件
+關注
關注
69文章
5332瀏覽量
91576 -
架構
+關注
關注
1文章
532瀏覽量
26589 -
微服務
+關注
關注
0文章
150瀏覽量
8102
發布評論請先 登錄
光伏四可裝置軟件系統架構:微服務化設計與容器化部署方案
基于OpenTelemetry的全鏈路追蹤微服務可觀測性實踐
Istio服務網格生產環境性能調優的最佳實踐
嵌入式軟件分層架構設計原則
RESTful API設計原則: 構建易用、可擴展的API接口。
RESTful API設計原則: 構建易用、可擴展的API接口
華納云VPS容器服務網格流量管理:實現微服務高效路由
基于RFID與微服務架構的智能倉庫管理系統:實現倉儲數據的全鏈路精準采集與管控
如何基于Nginx構建微服務網關
Jtti海外VPS微服務架構下的日志采集與分析優化方案
Jtti.cc零信任安全防護架構實施在VPS云服務器構建指南
深入剖析RabbitMQ高可用架構設計
電商API的微服務架構優化策略
蔡司“微服務”——全能在線售后管家,24小時守護您的設備!
設計微服務架構的原則
評論