當Uber公司某支團隊宣佈從微服務轉向宏服務時，腦子瞬時飄來幾個字“某種馬”。微服務還沒吃透呢，宏服務又來了，聽到宏服務這個名字，腦海中好像是聽說過，但是完全不瞭解。於是各種搜索，各種網站的信息翻了一遍。今天的主要目的是介紹為什麼要使用宏服務？
一、先從微服務說起
因為不是專門介紹微服務，因此我們直接給出微服務的定義。 James Lewis與Martin Fowler是這樣定義微服務架構風格的：
單個應用可以作為一系列小型服務的套件組合，其中每個小型服務都運行在自己的進程中，並且通過輕量級的機制實現彼此間的通信，這通常是 HTTP 和RPC。這些服務是圍繞著業務功能構建的，並且可以自動化獨立部署。每一種服務都可以通過不同的編程語言進行編寫，並且可以使用不同的數據存儲技術。
意思已經夠簡單明瞭了，假設是一個電商網站，註冊登錄就可以作為不同的微服務，他們相輔相成，又各自獨立，共同為整個系統服務。這樣來看微服務的優點不言而喻：
（1）每個服務都很簡單，只關注於一個業務功能。
（2）每個微服務可以由不同的團隊獨立開發。
（3）微服務是鬆散耦合的。
（4）微服務可以通過不同的編程語言與工具進行開發。
這麼明顯的優點，不知道哪一個叢林深處的團隊還未擁抱它。但是從github上的數據顯示已經很明顯了，基本上大多數公司不是已經用了微服務，就是還在使用微服務的路上。
不過凡事有利就有弊，微服務也不是十全十美的，這不就因為某些缺點，Uber就開始使用了宏服務。
下面我們再來看一下微服務有什麼缺點：
（1）硬件成本高
五個微服務可能需要佔據10個進程，如果要加入負載均衡和監控機制等等，需要的進程就更多了，這對於一些運維的硬件設施來說，成本真的太高了。
（2）需要DevOps
微服務的組織肯定需要DevOps ，畢竟微服務開發好了之後需要運維，這一下這麼多進程，我們還要保證每個微服務都能流暢的運行，還要保證不能把空間消耗殆盡，也就是說運維起來要保證時間和空間效率。
（3）複雜性
多個微服務就意味著是一種分佈式系統，既然是分佈式系統就不可避免的帶來複雜性和其他若干問題，比如說“網絡延遲、容錯性、消息序列化、不可靠的網絡、異步、版本化、應用層中的負載變化等等”。
（4）測試成本高
無論是手工測試還是自動化測試，這麼多微服務就需要都測試通過，而且微服務之間會進行通信，可能會帶來更多的測試。
（5）代碼重複
微服務中，可能有些功能是類似的，這也就意味著有些代碼重複寫了很多遍。
這裡就先列出這麼多，上面的這些缺點總結起來那就是一個系統拆分的微服務過多。各方面就開始麻煩起來。比如一個普通的電商網站，會拆分成幾百個微服務。需要的人力、物力、財力都是很龐大的。正因為如此Uber的某個團隊才捨棄了他。
既然微服務有這麼多缺點，是不是說微服務今後就要被捨棄了，實時證明是Uber公司依然在使用大量的微服務，為此我還查看了他們的github。微服務的數量也一直在增多。但是我相信這是一個勇敢的嘗試。
下面我們就開始今天的主題，介紹一下宏服務。
二、宏服務是個啥？
在創建新平臺的時候，Uber 支付體驗團隊對新服務進行了更加深思熟慮的規劃：不再只是完成一件事，而是使其服務於一項業務功能，由 5-10 個工程師負責維護。Gergely Orosz 把這樣的服務規劃稱之為宏服務。
其實可以通俗地來講，宏服務就是介於單體服務到微服務之間。宏服務關注的不再是某一個細節點，而是一個業務點。有一篇英文文獻中這樣描述宏服務：
宏服務應該定義為運行 2-20 個單獨服務的應用程序體系結構，每個服務代表一箇中等大小的代碼庫，可處理業務中定義明確的部分。宏服務的關鍵是拆分服務，最大程度地從拆分中獲得收益，同時最大程度地降低運行多個服務的開銷。
但是我覺得這篇文章有點問題，因為誰也不知道一個系統的業務點有多少個。因此宏服務的界限沒有一個嚴格的定義。
宏服務既然是單體服務和微服務之間的折中，也就會帶來很多的優點，比如運維成本會降低很多，既有了微服務的特點，又能在一定程度上解決了微服務的缺點。但是宏服務並非是比微服務更優的架構，只是架構演進中的不同選擇。將來會不會出現這樣一個宏服務框架，就由你或者他來設計吧！
OK。今天的文章先寫到這。
