微服務的設計原則

設計原則是從CSDN上吸收的其餘大神的經驗，記個筆記。

一 、單一職責原則單一職責原則指的是一個單元（類、方法或者服務等）只應關注整個系統功能中單獨、有界限的一部分。單一職責原則能夠幫助咱們更優雅地開發、更敏捷地交付，可是必定要注意職責的界限。

二 、服務自治原則服務自治是指每一個微服務應當具有獨立的業務能力、依賴與運行環境。在微服務架構中，服務是獨立的業務單元，應該與其餘服務高度解耦。每一個服務從開發、測試、構建、部署，都應當能夠獨立運行，而不該該依賴其餘服務。

三 、輕量級通訊原則微服務之間應該經過輕量級通訊機制進行交互。輕量級通訊機制應該具有兩點：首先是它的體量較輕；其次是它應該是跨語言、跨平臺的。例如咱們所熟悉的REST協議，就是一個典型的「輕量級通訊機制」；而例如Java的RMI協議則就不符合輕量級通訊要求，應該它綁定了Jave語言。樓主以前在某互聯網大廠的視頻部門的時候，就發現使用的是RMI協議，配置起來較爲繁瑣，且過重了。咱們通常都是使用REST協議。

四 、微服務粒度微服務的粒度是難點，也經常是爭論的焦點。應當使用合理的粒度劃分微服務，而不是一味將服務作小。代碼量的多少不能做爲微服務劃分的依據，由於不一樣的服務自己的業務複雜性不一樣，代碼量也不一樣。在微服務的設計階段，就應肯定其邊界。微服務之間應該相對獨立並保持鬆耦合。領域驅動設計中的「界限上下文」可做爲微服務邊界、肯定微服務粒度的重要依據。微服務架構的演進是一個按部就班的過程。在演進過程當中，經常會根據業務的變化，對微服務進行重構，甚至是從新劃分，從而讓架構更加合理。這也是目前樓主比較痛苦的地方，樓主的項目組已經通過了兩次微服務調整了。最終，當微服務的開發、部署、測試以及運維效率很高，而且成本很低，一個好的微服務架構就造成了。