上週六參加了魔窗組織的一個線上跨境茶話會Live的交流活動，主題是《微服務的挑戰》，雖然另外兩位嘉賓和我的背景各不相同，所在的企業的業務也完全不一樣，但是聊到後面，大家的觀點還是基本一致的。針對裡面的環節，選取了“微服務拆分”這個小議題，做了一個小結，談談個人的一點看法。

首先從基本原則看，我們拆分出來的服務需要實現一個強相關的方法的小集合，服務必須遵從共同封閉原則，一個服務的實現的更新和迭代不影響呼叫它API的消費端。

一個服務可以被3-5人規模的小團隊開發。每個人公司的情況不一樣，如果我們不考慮人的資源的情況下，我覺得一般是三個人就足夠了。因為有兩個方面的考慮，第一，微服務是相對封閉的，裡面是一條垂直的線，需要有專人去跟蹤。如果一個人維護有哪幾點不好？第一是力度過細，第二個是萬一這個人今天請假了或者是生病了，甚至離職了，那總要有一個人backup吧，避免出現系統性風險。

每個團隊應該是自主的，一個團隊可以自主開發和部署他們的服務。電商也好，互金領域也好，基本的方式就是根據業務能力來拆分。比如訂單、客戶管理、產品，我們都是按照這種方式來拆。但是實際上在業務維度之外我們還有一個領域概念，我們會把服務劃為三塊：

第一塊是基礎服務，它其實是跟業務關係並不大，但是能提供系統最基礎的功能，比如使用者、訂單，或者叫通用服務。

第二塊是支援服務，比如第三方的一些東西，比如發簡訊、支付閘道器，可能跟我直接業務沒有關係了，但是是對我的業務有一定支援作用。

第三塊就是核心業務了，核心業務比如我的審批流程，或者是風控，這是我的核心價值，那是一塊。我基本上是從這兩個角度來看，一個是業務，另一個就是領域。

 最後說一點，微服務拆分後，很重要的一點就是團隊工程師能力的提升，自我的驅動力必須要更高，因為工程師要對這個服務負責，需要深入瞭解業務的情況。第二個就是學習能力要更強，由於從前到後的相關知識都需要學習，不是說把介面暴露出來做好就可以了。對服務負責的要求，就是技術、業務你都要服務。當然反過來說，對於工程師個人的成長也打開了更大的空間。    

團隊發展到一定階段，會有一個架構師的角色或者是技術經理的角色，整個團隊相當於變成了一個球隊，架構師和技術經理對應於球隊教練的角色。作為主教練需要考慮這個球隊如何保持一個整體，一個球隊，分成中場、前端或者是後衛，怎麼保持他們的陣型，中間的配合是不是足夠到位，傳球順不順，中場和前場會不會脫節等等，這都是技術管理者要解決的問題。 

後續會有本次線上LIVE的完整版釋出出來，到時候分享給大家，歡迎更多朋友一起討論。

掃描二維碼或手動搜尋微信公眾號【架構棧】： ForestNotes

歡迎轉載，帶上以下二維碼即可

點選“閱讀原文”，所有【架構棧】近期的架構文章彙總

↓↓↓