淺談微服務拆分原理
業務需求開始的微服務拆分
Brobridge 在過去輔導的案例或顧問的客戶中，通常引入微服務架構碰到最大的困難，就是探討如何拆分微服務。尤其是，對於已經大量導入服務導向架構（SOA, Service-Oriented Architecture）的企業來說，根深蒂固的傳統服務拆分方式和看法，往往不經意的將微服務簡化理解為「顆粒度更微小的服務」或「拆解更細的 SOA 架構」。
在這樣先入為主的觀點下，許多企業就此陷入困境，因為對於大多數企業而言，SOA 的服務切分在技術上通常已經做到極致，甚至再切下去可能不見得有好處，反而有壞處。對企業來說，除了難以將既有服務拆分，不知如何下手，也覺得微服務的導入，只會講整個系統搞得更為複雜、難以維護。甚至質疑微服務架構，用系統複雜度換取微薄效能，是否真的有其必要性？
本文將試圖跳脫傳統 SOA 先入為主的概念，從 SOA 與微服務的服務設計概念異同開始，到幾個常見的微服務的原則，簡單推導並說明微服務拆分的核心原理和概念。
與 SOA 不同的服務設計概念
我們總是相信技術人員善盡其職責，在既有架構下做出最好的設計和選擇，已經將 SOA 的好處和概念發揮至了極限。只是其架構遭遇了極限，如果想要拆分出顆粒度更細的服務，光從既有的技術角度不夠，勢必要從別的面向來著手。所以，先理解微服務和 SOA 的設計概念異同，會有助於我們找到方向。
首先，從傳統的 SOA 服務設計來看，不外乎遵循著幾個原則：
- 可重複使用、粒度、模組性、可組合型、物件化原件、構件化以及具互動操作性
- 符合開放標準（通用的或行業的）
- 服務的識別和分類，提供和發布、監控和跟蹤
而微服務在服務設計基本概念上，與 SOA 有一些本質目標上的不同：
- 高度可維護、可測試
- 鬆耦合
- 可獨立部署
- 圍繞業務能力
- 歸屬於小團隊
從基本原則和目標上，可以發現傳統 SOA 的架構設計上，更偏向技術上的服務切分和設計，再加上長久以來程式開發的基本守則，「可重複使用（Reusable）」與「模組化（Modular）」通常會變成切分服務的主要考量。而微服務更關注於業務相關的需求，從業務能力出發來達成服務的切分，從不同角度出發，最終達成更顆粒度更細的服務設計。
從技術角度來說，理論上微服務走到最後，一樣會應用到 SOA 的各種技術方法，只是一開始的起手式不同，讓微服務有機會更好地滿足業務所需的效能和擴展性，並避開 SOA 的一些架構瓶頸。
微服務的服務設計基本概念
若理解了微服務是以業務導向當作出發點，重新看待整個系統設計，便不會對微服務在進行服務拆分時，會探討使用者情境、商業解決方案、商業流程而感到奇怪。此外，領域驅動設計（Domain-Driven Design）在其中所扮演的角色，也就很明朗了。
業務能力導向
SOA 因為著重於技術上的隔離和重用性，通常在這樣的設計下，外部需求被簡化，甚至在架構與服務設計上，不討論其上下文（Context）和使用情境。
而微服務架構的核心概念圍繞在「業務能力」，然後從實際業務的需求和流程長出對應的服務元件。若說白話一點，微服務的設計在進行技術性的模組化工作之前，會先引入企業的業務及商業流程管理的概念，以類似的標準作業程序（SOP, Standard Operating Procedures）的原理，先梳理出業務標準流程和標準事件，然後由這些標準流程和事件決定如何拆分服務。
試想一個工廠，一旦在實際業務執行面上達成標準流程的工作流水線，便可以輕易藉由增員或擴展產線來增加產能。同樣道理，若將資訊系統視為工廠產線，也可以藉由同樣方式，設計出一個因應實際業務需求而具有擴展性、產能的系統。
使用者情境和流程的關注
由於微服務圍繞是圍繞在業務能力上進行設計，使用者情境和流程因此非常重要，在梳理服務之前，會將使用者情境整理好。然後，因應使用者的行為、過程中所觸發的事件和需求，設計出對應的服務。
後記
在微服務切分時，技術議題不放在第一位。或許，有些服務可能在不同流程或階段需求會被重複利用，但在微服務的架構設計實務上，不會過早討論技術上重複利用（Reusable）的議題。
這與技術領域上過早優化的情況雷同，有些服務因為優化開發過程等理由而合併，反而會產生效能問題或是其他後遺症。所以先盡量讓服務流程完善，流水線完整，再去考慮其中的細部的技術和模組化議題，是比較妥當的做法。
最後，如果您對「微服務架構設計」以及「微服務拆分」的議題仍感到疑惑，可以與我們 寬橋（Brobridge） 聯絡，取得專業的教育訓練和顧問服務。
