微服務的未來？ 更多抽象！ - thenewstack

banq發表於2021-07-30
微服務抽象

微服務於10 年前出現，是軟體中發生融合進化的例子之一。雖然這個詞可以歸功於全球軟體顧問Thoughtworks 的James Lewis和 Martin Fowler （banq注：這個詞應該首先由亞馬遜提出，也就是著名“一個披薩”，開發一個微服務的人員正好夠吃一個披薩 ，MF只是進行了微服務這個名詞詳細定義），然後許多其他矽谷公司Netflix 、谷歌和eBay 在大致相同的時間各自獨立或多或少實現相同架構模式。
在這個術語被創造出來的十年裡，我們看到了 Kubernetes、服務網格和無伺服器的興起，我們也開始看到微服務對前端的影響。除了水平擴充套件實踐，微服務還允許開發人員更快地部署程式碼，支援元件的可替換性而不是可維護性。
無論好壞，微服務已成為許多人的預設架構選擇。對於擁有自治團隊和鬆散耦合系統的組織，微服務可以很好地工作，但它們帶來了使用任何分散式系統時固有的複雜性。
考慮到這一點，進入微服務時代的十年後，思考我們已經達到的目標以及我們仍然需要解決的問題是很有趣的。
 

歷史回顧：部署和執行時
現在有各種各樣成熟、設計良好的微服務框架，涵蓋了大多數語言的基礎知識，在 JVM 上有大量選項，包括Spring Boot、Dropwizard、Helidon、Lagom、Micronaut和Quarkus，以及Go等選項用於 Go 的工具包、用於 Python 的Flask和Falcon、用於 JavaScript 的Node.js等等。
同樣，良好的監控選項比比皆是。OpenTelemetry的出現尤為重要。它由 OpenTracing 和 OpenCensus 合併而成，擁有廣泛的供應商和語言支援，為分散式遙測資料的外觀提供標準化。這意味著開發人員只需對他們的程式碼進行一次檢測，然後就可以交換和更改監控工具，比較競爭解決方案，甚至可以在生產中針對不同需求執行多個不同的監控解決方案。
然而，當我們檢視部署和執行時，情況變得有點模糊。Kubernetes 或多或少已成為微服務的同義詞，但其複雜性日益增加。
Spotify新工程師需要花費60日才能合併他們的第10 pull請求，對此，該公司剝離了開發者入口網站、後臺，現在使用沙盒專案封裝雲本地計算基礎。
Netflix非常重視 DevEx，為開發人員“鋪平道路”，加速採用GraphQL等新技術。同樣，我們已經看到了內部構建和透過像Humanitec這樣的供應商構建的開發者平臺的興起。Ambassador Labs有一個與開發人員控制平面相關的概念——它的網站聲稱，“使開發人員能夠控制和配置整個雲開發迴圈，以便更快地交付軟體。”
Kubernetes 對開發人員不友好。令我震驚的是，我們仍然沒有在 Kubernetes 之上廣泛使用的良好、可靠、類似於Heroku的抽象。
 

未來趨勢1：將服務網格隱藏在抽象背後
服務網格被推入更深的平臺，並且在很大程度上對開發人員隱藏。例如，紅帽 OpenShift在幕後整合了 Istio，並且有多個類似的舉措將服務網格與公共雲平臺更緊密地整合在一起，例如AWS App Mesh和Google Cloud Platform Traffic Director。
還有一些工作以減少服務網格引入的網路開銷。一些最有前途的工作是Cilium團隊的工作，它利用Linux 核心中的eBPF功能來實現所謂的“非常高效的網路、策略執行和負載平衡功能”。
Ambassador Labs 開發者關係總監認為：我認為現在我們需要為我們其他人提供領域驅動設計。因為即使是普通開發人員而不是架構師也需要對如何確定實體和邊界的範圍有一定的瞭解，其中很多都可以追溯到良好的 API 設計。
另一種隱藏服務網格可能性是我們可能會完全轉移到不同的執行時：函式為一種服務（FAAS）/無伺服器將最終取代Kubernetes作為分散式應用的事實標準執行，我們也看到了一些真實世界的生產例項其中，例如BBC，其 大部分線上架構已從其先前的 LAMP 堆疊直接轉向Amazon Web Services上的Lambda。
 

未來趨勢2：面向業務抽象的自治團隊架構

Eric Evans 的領域驅動設計是微服務運動的基石，任何軟體架構師都應該閱讀。但更進一步：即使是普通開發人員而不是架構師，也需要對如何確定實體和邊界的範圍有一定的瞭解，其中很多都可以追溯到良好的 API 設計。一旦你理解了耦合和內聚的重要性，關注點和邊界的分離，你就會自然而然地投入到你正在處理的任何抽象（模組、類、服務、應用程式）中。
Newman 的書《構建微服務》即將出版的第二版介紹了許多這些概念，並考慮到了下一代服務。

更多點選標題
 

相關文章