# Microservice Pattern 犧牲了什麼？

軟體工程Microservice 是目前非常流行的 Architecture Pattern ( 應用程式會拆分成多個 service 聯合運行，通常會透過 RPC call 進行交互 )，進而推動的 Distrubution System 相關知識在Backend 領域中越來越顯德重要。延伸的主題，Event Driven, Event sourcing, Distribution lock.... 

只是 Mocroservice 的缺點也是顯而易見的，以下缺點都是相對於 monolithic 架構：

1. Performance issue
   1. 相對於 monolithic 架構（全部寫在同一個application），會增加網路傳輸的物理時間以及加密解密封包的效能損耗
2. Development Speed
   1. 由於一個 Application 切成幾個區塊(services)進行開發，同時 scripts 行數會變多，需要考慮到分散式系統的各種 issue. ex: Transaction atomicity issue
3. Management Service
   1. Deployment issue: 因為多增加了 Services ，因此需要部署跟設定的步驟也會隨之變多。
   2. Indepenccy Service issue: 個服務的相依性容易造成系統修改不易。

### Evaluation

最後結果為 Monolithic 的實作方式，可以增加 15倍左右的效率

實驗參數：

* GKE(Google Kubernetes Engine) K8s，並開啟 Auto-sacling Rescurces
* Comparision 
  * Monolithic
    * component 之間的傳輸，以 Unix PiPE 取代 RPC Call，即 \[3] 專案，是以 \[2] 專案為基礎進行開發
    * 實作語言 GO
  * Microserivce
    * component 之間的傳輸以 gRPC，且有 11 個 services 交互運行，即參考資料的 \[2] 專案
    * 實作語言 GO

<table><thead><tr><th width="178">Metric</th><th>Monolithic</th><th>Microservice</th></tr></thead><tbody><tr><td>QPS</td><td>10000</td><td>10000</td></tr><tr><td>Avg of CPU Cores</td><td>28</td><td>78</td></tr><tr><td>Latency (ms)</td><td>2.66</td><td>5.47</td></tr></tbody></table>

### 結語

Microservice Pattern 是以 Service 為單位將大型 Application 進行拆分，會產生管理上的難度以及物理上所造成的效能缺失，文章中所提到的實驗有15 倍以上的差異。

而 Microservice 所帶來的好處是非常顯而易見的：

1. Easy handle single service failed
2. Easy parallel develop in cross-team
3. Easy scalling up for specific services

因此 Microservice 不是一個不好的 pattern ，而是思考這樣的架構是否合適。

### Reference

\[1] Ghemawat, Sanjay, et al. "Towards modern development of cloud applications." *Proceedings of the 19th Workshop on Hot Topics in Operating Systems*. 2023.\
\[2] Online boutique. <https://github.com/GoogleCloudPlatform/> microservices-demo, 2023.\
\[3] github.com/ServiceWeaver,2023