服務、微服務與無伺服器之函式的區別？ - Tom Nolle

從一端到下一端
“服務”，原始的元件化戰略，至今仍在使用。按照慣例，服務是執行某些特定業務的應用程式的功能元件。面向服務的應用程式可能具有“新增員工”，“付錢給員工”，“更改員工資訊”等服務。業務活動，業務流程和業務事務決定了元件化。

顯然，這些都是單個應用程式的元件（在我的示例中屬於工資單/人員管理應用），雖然它們總體上比應用程式小，但它們實際上並不是很小，並且它們也不是特別容易重用。您無法輕鬆地將“付錢給員工”納入客戶資源管理應用程式或檢查處理。

這些元件服務通常也以特定方式實施。它們是會持久狀態資料的，意味著它們被假定為始終可用，並且是有狀態的，這意味著它們在事務之間儲存資訊。前一種情況意味著它們不被使用時也會浪費雲中的資源，因此而必須為這些服務元件始終線上可用而付費，雖然經常不被真正使用！同時，由於在多個事務之間儲存資訊，這是由狀態的，就無法透過建立多個副本來共享負載來擴充套件性能，因為相同的資訊不會儲存在原件中的副本中。

“函式功能”是另外一種情況。函式是一個軟體元件，其輸出完全取決於輸入; 沒有內部儲存或使用。Output = 2xInput1 + Input2 是一個非常簡單的函式的示例。函式顯然很小並且是通用的，因此您可以輕鬆地重用它們，並且因為輸出只是輸入的函式，所以您可以為函式的任何副本提供輸入並獲得相同的結果。這使它們具有完全可擴充套件性和彈性。由於無伺服器計算僅在使用時才載入，因此這些屬性對無伺服器雲至關重要。另一方面，它們在資料中心中並沒有那麼明顯有用，因為元件保持駐留可以提供效能優勢，而不會產生增量的雲服務費用。

微服務並非全是啤酒和玫瑰
“微服務”也許是雲時代應用程式元件的所有新術語中最令人困惑的。谷歌傾向於使用這個術語來表示與函式大致相同的東西，但在開發人員中，這個術語似乎具有不同的含義。對於他們來說，微服務是一個小元件，它共享函式的無狀態屬性，但就像服務一樣，它們是持久的。

“無伺服器的函式”在使用結束後就結束，但微服務往往會部署並保留在原地以供連續使用。這使得它們成為服務和函式之間的一種方式，這可能就是為什麼微服務似乎主導應用規劃的原因。它們很容易接受，它們在雲端和資料中心都很有用。

然而，微服務並非全是啤酒和玫瑰。將應用程式分解為可分發元件的任何策略都有其自身的風險。最明顯的是，單獨的元件意味著將工作從一個網路移動到另一個網路，這需要花費大量時間併產生連線丟失將導致應用程式故障的風險。

如果微服務小於服務，則會出現更多服務，從而導致更多的網路延遲和風險。如果申請沒有經過精心設計，兩者都會加劇。例如，與單個事務相關的十幾次呼叫的微服務也會使延遲和風險增加十倍。最好避免使用可能存在這種迭代的微服務。

無伺服器函式功能也可能被濫用。您只需支付在無伺服器雲應用程式中執行的內容，但是當您將函式功能用於不經常執行的內容時，這是最有價值的。如果一個函式每小時被呼叫數百次，那麼它肯定會比它成為微服務時保持駐留時的成本更高 - 不如轉成為微服務。

總結
元件化在開發和執行應用程式方面都有好處，但即使它已經存在了幾十年，我們仍然在努力應對這些好處的不利因素。服務，微服務和函式功能都是構建基於元件的敏捷應用程式的方法，甚至這些術語對許多人來說都很困惑，這意味著在雲時代構建應用程式需要特別小心。