微服務構建思路與方法論
微服務規劃、微服務構建、微服務協同、微服務測試、微服務治理、微服務下線等是企業採用微服務必須面對的微服務生命週期管理問題。我們討論過微服務治理的問題，由於一些原因未能整理微服務拆分、微服務設計、微服務構建等相關內容。網上對微服務的討論更多是微服務開發框架的使用，較少深入討論微服務拆分、設計和構建。我們提出過採用主資料思想來構建微服務體系，目前也有采用DDD方式來設計微服務的，這裡我們探討下微服務構建的一些思路和方法，以期拋磚引玉，帶來更多更深入的探討。
一、 採用微服務的目的
採用微服務，首先要有明確的目的，有清晰的認知。微服務並不是放之四海而皆準的理論，有其適用範圍和場景。如果用單體應用能輕鬆解決的問題就沒必要用微服務架構。在遇到有分散式、彈性擴充套件等需求的情況，才需要考慮微服務架構。一個微服務我們可以認為其是一個小的單體應用。在有很多單體應用之間需要通訊、協同的情況下，或者通過單體應用之間的整合無法滿足業務效能要求，需要重構業務應用系統時，才需要考慮採用微服務架構。
我們也提到過，微服務意在重構！並且通常在大中型企業有眾多的單體業務系統情況下，各單體業務應用整合可能成為一個問題的時候，需要考慮採用微服務架構重構業務應用。由於微服務架構體系需要眾多的基礎設施平臺和基礎元件支撐，才能發揮微服務架構的優勢，所以一些小公司或者沒有計劃進行大規模改造的情況下，採用微服務可能無法展現其價值，並且管理任務有可能更多、更繁瑣。
服務化的目的在於重用，微服務也是一樣。其實無論函式化、模組化、元件化、服務化等重要目的在於共享、重用。技術經過若干年後總會以另外一種面貌重現，就像當前的Serverless 函式程式設計，原來單體應用的函式放到雲端，加個Serverless的概念馬上就高大上了。微服務還有重要一點在於其分散式彈性，微服務例項數彈性伸縮，可以和容器平臺結合，利用容器彈性伸縮的特性，實現微服務的彈性，快速響應業務變化需求。
採用微服務往往也是因為其輕量，可以快速迭代，即時響應新業務需求，快速開發部署微服務應用，在搶佔市場的同時可以持續的迭代和完善。所以通常採用微服務是以業務需求變化快的場景為起始，比如活動促銷等，然後逐步推廣到其他業務場景。
二、 構建思路，方法論
跟很多廠商交流微服務，基本上都在談SpringCloud、Dubbo，談到用什麼理論或方法來指導微服務的設計和構建時，幾乎沒有廠商關注這些，感覺大部分人也就是用微服務開發框架去寫程式碼，至於微服務設計和構建，則基本上還不具備相應的能力。沒有理論指導，每個人理解的微服務可能都不一樣，所以實現出來的微服務也就五法八門、千奇百怪了。
都知道微服務是一種架構方式，但怎麼架構？什麼是合適的微服務架構？可能就仁者見仁、智者見智了。如果僅知道SpringCloud，那也就是一個編碼人員，不具備微服務設計和構建的能力。微服務設計和構建則需要相應的理論功底，比如比較流行的DDD領域驅動設計方法，但領域驅動設計側重業務領域，而且整個體系複雜，業務領域專家所設計的領域模型並不一定適合技術實現，需要技術人員的二次建模，最重要的是資料的儲存未充分考慮。微服務可能根據資料的量、請求負載的量、資料的型別、來源等採用不同的儲存方法，可能需要考慮分庫、分表、分割槽、物化檢視等不同的方式，也可能隨著業務資料的變化而更新微服務的儲存和實現。我們認為這才是微服務設計和構建需要重點考慮的方面。至於用什麼工具開發，那是次要的選擇。
如果瞭解主資料管理（MDM）的話，我們建議採用主資料的思想來構建和設計微服務。主資料強調唯一資料來源。主資料管理是實現主資料整合和治理，主資料是資料的骨架，其他資料是血肉，它們共同構成一個完整的企業資料整體。主資料並不是不關注業務，恰恰是從業務流程梳理開始，只不過我們不是構建一套主資料管理系統，而是以主資料的思路來構建微服務資料模型和儲存模型。談主資料可能需要了解通用資料模型CDM，它非常有助於我們構建適合的微服務資料模型。
當然，我們覺得兩種方法結合可能會更好一些。目前只是理論上的思路，具體還缺少實踐，所以也希望能充分和有這方面考慮的團隊或個人深入交流。
三、 重點在資料
微服務重點不在採用什麼語言或什麼開發工具，我們曾經討論過SpringCloud/SpringBoot不是微服務，SpringCloud/SpringBoot開發的服務也不一定就是微服務。微服務是一個從業務層到資料層到儲存層都是相對獨立完成特定功能的一個單元，所以我們經常聽到拆庫、拆表的討論，但缺指導性的一些原則和方法論。微服務重點在資料，因此採用微服務和資料治理能力密切相關。資料標準、資料安全、資料所屬、資料模型、資料持久化等直接影響著微服務的質量和實施難度。什麼時候資料存放資料庫？選擇什麼資料庫？什麼時候需要分割槽表?什麼時候分表？什麼時候需要分庫？非結構化資料如何處理？……這些不是選擇一個開發框架就能解決的問題，這才是微服務設計和構建的重點。
通常情況下需要考慮由原子微服務來準備資料。不同的場景資料準備的方式可能是不一樣的。不過在當前的大多數業務場景下，實時及準實時的需求越來越多，所以資料準備需要在原子微服務中以實時或準實時的方式準備好。可以是高效的主動獲取，也可以是被動的實時更新，但要確保資料的正確、準確。而關於用業務微服務和應用微服務封裝業務邏輯和應用元件協同邏輯，我們將在下一篇《微服務協同》中詳細討論。
四、 提取基礎元件
採用微服務在梳理完業務應用流程之後，首先就需要考慮提取基礎公共元件。這些元件是每個應用系統都可能需要用到的，所以這些元件需要首先提取出來。比如日誌服務、監控服務、告警服務、統計服務、許可權服務、認證服務等。採用微服務架構還會涉及微服務註冊發現、微服務配置、微服務閘道器等。這些服務通常也有開源的元件，可以協助構建整個微服務體系基礎元件服務。但開源的畢竟只是在技術上可行，應用於實際的業務環境還有不少的工作要做，後期技術支援也是個需要認真考慮的事項。
在提取完非業務性功能元件服務之後，可能需要考慮業務性功能元件，比如公共資料字典服務、資料標準轉換服務、資料分發規則服務等等。這些服務和整個業務微服務設計架構緊密相關，是其他業務微服務需要共享使用的，提取這些微服務將有助於快速的構建其他業務微服務，快速敏捷的推進微服務建設。
五、 基礎設施支撐
微服務不是開發幾個所謂的微服務就ok了，它需要眾多的基礎設施支撐才能更好的體現微服務的價值。微服務的開發、測試、部署、治理、運維等整個生命週期過程都需要各種設施的支援。比如基礎設施資源平臺，可以提供虛擬機器、儲存等資源服務。資料治理平臺在設計構建微服務時有相應的資料標準和資料安全等支援。服務管控平臺則提供微服務的部署、運營管理。介面管理平臺提供微服務對內對外的標準API服務等等。
微服務意在重構，並不是為了某一個應用系統，而是要考慮企業內的所有應用系統，這些應用系統的公共的服務，首先就是共享，這是重構的意義所在。
六、 量變到質變，持續的過程
我們想強調的是，微服務設計和構建不是一步到位的。它是一個持續構建、持續優化的迭代過程。就像前面我們提到的，隨著資料量的變化，微服務的實現可能需要優化，這是一個迭代的過程。資料量小的情況下可以一個庫一張表，但資料量巨大的情況可能需要考慮分表、分庫，甚至分割槽域資料中心。資料物理儲存模型的改變必然導致微服務實現的變化。還有就是資料來源的變化，微服務協同的變化等都會帶來微服務實現的調整。
微服務初始實現的時候可能也就幾個、十幾個或幾十個微服務。不過在重構第二個業務系統的時候就會簡單些，公共的元件服務不需要再構建了，直接可以使用。關注的重點是業務邏輯在業務微服務中的實現，公共的能力比如日誌、配置、許可權等只需要按照標準的服務介面呼叫相應的服務就可以了。還有一些公共的業務微服務元件可以共享，比如資料字典服務、一些公共的服務比如客戶服務、產品服務、賬戶服務等。所以隨著微服務構建的增多，在重構一個應用系統時將會越來越容易，越來越便捷，越來越快速，越來越敏捷。
其實我們覺得微服務的構建過程也會符合二八規則，前期做80%的工作可能只實現了20%的業務需求，但隨著量的增加，後期20%的工作就可以實現80%的業務需求。這就是服務共享的收益。
到後期，也許就沒有原子微服務的構建需求，更多的是業務應用微服務的構建，在一個業務需求提出後，選擇合適的原子微服務或業務微服務通過流程配置就可以快速的釋出部署，真正實現對業務需求的敏捷響應。