什麼是迷你服務Miniservices？

你還真的使用微服務嗎？
Martin Fowler對微服務架構的定義：

1.可獨立部署和可擴充套件的可執行檔案
2.有單個職責
3.松耦合

（banq注：按照這個定義第三條，微服務之間必須松耦合，但是這個松耦合松到什麼程度？執行時透過服務註冊中心相互發現，算不算是松耦合了？至少在雲原生應用的規範中這個是滿足了，那麼從設計上看，儘管服務發現是動態的，但是服務呼叫還是透過介面耦合，這算不算松耦合？因此這種松耦合判斷標準大家是有歧義的。松到只依賴對方介面算不算松耦合？其實這就是RPC，還是松到只依賴對方的JSON資料？這是REST方式，還是松到只依賴對方發生的事件？這就是事件驅動的pub-sub方式，本文觀點認為真正微服務是應該基於最鬆散的事件驅動方式，否則就不是純粹微服務，而是迷你服務）

Cloud Elements營銷副總裁羅斯·加勒特告訴The New Stack，大多數團隊都在努力盡可能地分佈分散，但他們並沒有像他們想象的那樣使用盡可能多的微服務。

他說，微服務架構應該是一個基於訊息的系統，微服務可以透過這個啞管道彼此非同步通訊，而現在很多現代開發人員都不熟悉這種訊息通訊層。很多跡象表明他們又回過頭去使用HTTP了。

“HTTP作為一個請求/響應模型是簡單的，它很好理解，每個人都能理解如何使用RESTful方式進行通訊，”Garrett說，但如何解決Martin Fowler所要求的鬆散耦合呢？ 因為在HTTP中，服務必須事先彼此瞭解(客戶端和服務方都需要彼此瞭解)，因此你必須圍繞每個服務編寫API介面程式碼。

Fowler認為這些服務應該完全獨立存在，使用HTTP構建服務必須更多地瞭解它周圍發生的事情才能進行通訊（banq注：比如掌握JSON或API等知識），並且比定義一個微服務需要掌握更多。

“在真正的微服務架構中，每個服務都應該對其周圍的服務沒有任何意識，為了實現這一點，必須存在一個非常特殊的通訊模式，即pub-sub（釋出/訂閱模型，不同於RPC同步的生產/消費模型），訊息或事件被髮布在訊息佇列中，這樣其他人可以訂閱消費使用它們，這是最鬆散的耦合，“加勒特解釋道。

“然而，在應用程式開發中，並沒有很多開發人員熟悉pub-sub這種訊息佇列整合模式，因此他們只能迴歸到使用REST API作為使服務之間通訊的一種方式，然後因為他們使用REST，他們必須知道你的所有服務，這樣你又失去了松耦合，“他繼續說道。

Garrett說，開發人員會在將這些應用拆分成最小功能元件，這些元件仍然讓你進行通訊，但如果他們使用HTTP通訊，則無法完全獨立。

加勒特又說，好了，現在是時候接受“miniservices迷你服務”了，大多數公司其實都在使用它們，他說範圍或大小並不重要，因為miniservice根本就不是純粹的微服務。

“[miniservice就像一組微服務以一種小模式聚集在一起。”
- 羅斯加勒特

“這幾乎就是一組微服務以一種小模式聚集在一起，因為他們必須彼此瞭解，”加勒特說。(banq注：迷你服務比微服務顆粒度更大些)

自稱為API Handyman的Arnaud Lauret以這種方式劃清界限：“miniservice似乎是一種實現微服務更簡單、更實用的方式，例如，每個微服務必須處理自己的資料，而miniservices可以共享資料。“

“每個微服務必須處理自己的資料，miniservices可能會共享資料。”
- Arnaud Lauret

這一切都進入了事件驅動架構的世界，透過請求/響應模式對它們關心的事件作出響應。加勒特解釋這些服務的動作行為就像：“我必須告訴你一些事情，但我不能只收到一個隨機事件”，然後就會偏離微服務架構的樣子。

他說，如果你問一個公司他們是否在使用微服務，答案總是“當然”。

“現在流行的更多是關於開發人員對整合模式和技術的理解，而不是人們建立小型服務的願望，”加勒特說。“我會說，除非你已經使用HTTP作為這些服務進行通訊的一種方式，否則你就是在做miniservices迷你服務。”

在架構之前的用例場景
無論你是在進行微型服務、小型迷你服務甚至是單體式系統，這些並不重要，它與你的架構決策的業務影響有關。如果你能夠獲得所需的解決方案而無需達到純粹的微服務的話，那就無所謂了。

“不要將完美架構與商業價值混為一談。”
- 羅斯加勒特

加勒特說，這一切都是為了做出正確的商業決策，理解你為什麼要做出改變，以及理解你想要解決的問題。

IT分析公司Gartner的研究開發人員Gary Olliffe最近發表了題為“ 你不是Netflix：如何或何時在企業中使用微服務”的演講。正如其名稱所暗示的那樣，Netflix是最具架構性的前瞻性思維之一公司,它們公司面臨著特定的挑戰，主要是可以透過微服務可以解決，但是，僅僅因為微服務適合他們，卻不意味著微服務適合你。Netflix必須瞭解它們需要公開其服務的不同端點，並且在各種不同約束的不同裝置上公開它們。微服務通常是這種情況的正確選擇，但就是在這種情況下，他們仍在使用HTTP。

加勒特說這不是微服務的純粹主義看法，而是微服務在功能上幫助他們正確實現了他們的目標。對我來說，關鍵點是我如何解決自己的特殊問題以及我有什麼技能來解決它​​。“

LaunchAny數字化轉型諮詢公司創始人James Higginbotham 將這種對微服務的認可看作是朝著正確方向邁出的一步，他稱之為“模組化單體”。

“看到模組化思維 - 以及松耦合和高凝聚 - 重新進入我們的軟體設計是令人興奮的。微服務是一個適合少數人的極端，它的教訓可能適合許多人。“

“公司可以選擇：構建模組化單體架構或使用微服務構建，團隊可以有效地分配工作，但微服務架構的原則有助於管理複雜解決方案帶來的挑戰，“他說。“微服務的缺點是它們將複雜性推向了極端，訣竅是找到適當平衡的地方，反而可以利用複雜性來提高公司的效率。“

何時使用Miniservice vs. Microservice vs. Monolith
微服務工具提供商KintoHub的創始人兼執行長Joseph Cooper 分享了他在遊戲行業後端解決方案程式設計方面15年的經驗教訓，他說他們有一系列獨特的問題可以透過miniservices、微服務和單體架構的大雜燴方式來解決。

對於Cooper來說，miniservices就是將一個功能作為一個服務來執行。“miniservice是一個功能即一個服務，”他說。他舉了一個例子，“當你使用lambda和Google函式，並且你想要確保最大化節約成本時，比如你不想啟動一個完整的函式，而只是想啟動你想要的函式。”

他說，當你有更高的複雜性時，miniservices是可靠的解決方案，比如影像處理，他說這是一個非常簡單的程式，不需要與其他服務之間進行任何通訊。

另一方面，“對於微服務來說，好處是你的產品中包含更多程式碼，它們可不節約成本（雲端計算廠商以計算執行時間多少為收費標準），因為您必須實時載入多個函式，或者必須讓它們始終執行。“

他繼續說道：“有時他們並沒有serverless無伺服器的味道，[你的服務]一直在執行 ，成本優勢會丟失，但好處是在單個服務中提供更多函式，使他們更容易使用和理解。“

如果您的專案在多個程式碼庫中有一個功能，則微服務是一種合理的解決方案，另一方面，Cooper表示，如果您正在執行一個電子商務網站或遊戲，您可以在一個儲存庫中擁有十個或更多功能，有時一個需求功能feature可能需要更多功能配合才能完成，而miniservice更適合這種需求。

並且不要忘記迷你服務不僅僅是微服務發展趨勢，而且已經是新興的、真正現實的服務的解決方案。例如，釣魚遊戲EatMe.io將在一個房間內擁有多達一百名全球併發玩家，遊戲在12個不同的亞馬遜網路服務區域執行，這擴大了他們面臨的最大挑戰。除此之外，在15場比賽中，只有7場比賽栩栩如生。為了快速實驗和迭代，他們將在整體上進行原型設計，然後分解為miniservices或微服務。

“基於單體monolith概念能更好建立概念證明，因為它更容易管理，然後在你的概念證明之後，你知道你的MVP [最低價值產品]是什麼，那麼你可以重新開始並用微服務構建它，“Cooper解釋道。“有時候你不知道你的產品會是什麼樣子，如果你是直接在微服務上構建產品，那麼你會投入太多時間進行概念驗證。”

他還表示，如果遊戲的新版本不再出現，但他們想維持當前版本，他們將利用miniservices在最大限度地節省成本。

Miniservices as a Realistic Alternative to Microse