1.4 微服務時期

1.4.1 服務細化

微服務是2012由Martin Fowler提出的概念，并沒有嚴格的定義。從本質上來說，分布式經過前一輪的服務化后，應用本身臃腫復雜的問題已經得到了很好的解決。不過微服務則希望將其更進一階。這里的重點就是“微”，即一個服務只負載一個獨立的功能。此時，傳統的“用戶中心”服務，對于“微服務”來說，根據業務需要可能就需要再次拆分，例如針對電商場景，可能就需要拆分成“買家服務”“賣家服務”“商家服務”等。

至于到底需要拆分到多細，這里的原則便是，任何一個需求不會因發布或者維護而影響到不相關的服務，一切可以做到獨立部署運維。當然，甚至可以拆分到一個獨立的功能、一個服務，肯定就不會相互影響，這也正是Serverless思想所提倡的。不過Serverless尚需要較多的基礎服務支撐，而且還沒有被主流公司接受，因此服務的拆分粒度，現在仍然是一個沒有明確界限的事。

1.4.2 架構輕量化

“微服務”所強調的不只是服務劃分粒度上的“微”，同時對整個架構也有更高層次的要求。例如“微服務”希望遠程調用協議是非常輕量級的，它不提倡使用像Dubbo這樣的強語義協議，因為每種語言都需要一個針對性的客戶端，而且客戶端邏輯還比較復雜，甚至還支持編寫Groovy語言來自定義擴展。

廣為大眾所接受的Spring Cloud框架是微服務的典型代表。相對于傳統分布式服務架構，Spring Cloud使用HTTP作為RPC遠程調用協議，配合上Netflix貢獻的Eureka與API網關Zuul，其能做到細分內部服務的同時對外暴露統一的接口，讓外部終端對系統內部分布式架構無感知。此外，Spring Cloud的Config組件還將配置與上述各框架結合起來，讓每個服務都可以非常簡單地接入并配置系統。

綜上所述，在我看來，“微服務”所強調的輕，其實就是反映工程師們普遍不希望分布式相關架構邏輯侵入業務系統的事實。在傳統的分布式服務架構中，一個服務（應用）通常要非常多的配置才能正常工作，例如Dubbo需要填入配置中心地址、配置Service接口XML文件等，并且要求對方也接入Dubbo客戶端才行，而Spring Cloud則只需要通過幾個簡單的注解即可完成對服務調用的聲明，因為是基于HTTP的，即便是不同語言，也可以很好地支持。

縱觀整個分布式發展史，微服務時期可以說是一個發展的分水嶺，因為此時工程師們真正開始注意到架構本身帶來的復雜性。在此之前，分布式都是往做多做細方向發展，例如之前“集群化”“服務化”“服務治理化”等一系列過程，都是一種架構擴展演進。而微服務在細化的同時，首次提出了“微”，即輕量級的概念，在此之后，分布式架構便進入了一個架構收縮的過程，因為其本身已經太復雜了，工程師僅是理解業務估計都需要好幾天，因此需要讓他們盡量少地去感知架構的存在，甚至做到完全無感知。

要知道，所有這些對于加班如家常便飯一般的工程師來說，那是一件非常幸福的事。