微服務是一個越來越熱的話題，討論的問題都大致是我有一個單體大應用，如何拆成微服務？如何拆了微服務，使得微服務之間的耦合度較低？服務之間調用的性能問題？分佈式一致性問題？現在也有越來越多的討論微服務與組織架構的對應關係，但大多討論的是R&D內部的組織架構關係。太多太多的聚焦都在技術和技術組織本身，在很大概率情況下，你跟你公司的CEO，COO聊這樣的話題的時候，他們不睡着就是萬事大吉了。
去年8月的時候，我所在的公司入住了微軟加速器第八期孵化企業，微軟加速器邀請往期校友智齒科技的CEO徐懿的一次分享，智齒做的是toB的智能客服生意，徐懿分享了他們跟客戶溝通時，跟客戶聊什麼，客戶會感興趣。在很多情況下，客戶都會對三類事情感興趣：增加收入、減少成本、管理提效。而在這三類事中，感興趣的程度在很多情況下是：
增加收入 > 減少成本 > 管理提效
這個觀點觸動我了。對R&D而言，R&D需要給業務支撐，需要在R&D上給業務提供競爭力。那到底怎麼判斷衡量做什麼、不做什麼、怎麼做呢？完全可以簡單的通過依次問三個問題來回答：
1. 在我所在的領域，使用了這個技術，可以幫公司（或客戶）增加收入嗎？如果是，是怎麼做到的？
2. 在我所在的領域，使用了這個技術，可以幫公司（或客戶）減少成本嗎？如果是，是怎麼做到的？
3. 在我所在的領域，使用了這個技術，可以幫公司（或客戶）管理提效嗎？如果是，是怎麼做到的？
所以，同樣的，當我在聊微服務的時候，我更希望的是從增加收入、減少成本、管理提效這三個角度來說。所以，再來一遍就是
1. 在我所在的領域，使用微服務，可以幫公司（或客戶）增加收入嗎？如果是，是怎麼做到的？
2. 在我所在的領域，使用微服務，可以幫公司（或客戶）減少成本嗎？如果是，是怎麼做到的？
3. 在我所在的領域，使用微服務，可以幫公司（或客戶）管理提效嗎？如果是，是怎麼做到的？
同理，在拋開了技術本身內部依賴性的前提下，微服務拆分時的優先級應等於上述三點的優先級。
下面就用分時租賃汽車共享（car-sharing）領域來做例子。分時租賃汽車共享業務，可能很多人還不太瞭解這個比較新型的業務。相比於傳統的汽車租賃業務而言，分時租賃瞄準的是更加碎片化的汽車租賃業務，用戶不再需要到門店走繁瑣的租車流程，通過APP就能完成汽車租賃，開關車門等操作，更加便捷，並且只需要根據使用的時間和里程進行付費，大多在1.5元一公里，0.2元一分鐘左右，按需付費共享，也更加的環保。比較老牌知名的公司有戴姆勒旗下的car2go。
如果我們把car-sharing描述成一個單體應用，大體如下圖所示：
當我們講我們的領域聚焦在智能出行、car-sharing業務以後，就可以開始問三個問題：
1. 在智能出行領域，使用微服務，可以幫公司（或客戶）增加收入嗎？如果是，是怎麼做到的？
通過微服務本身來增加收入的方式有很多種，其中一種最顯著的是，但卻相對討論比較少的是，微服務本身不僅僅是指技術IT微服務，更不僅僅是指你部署的server是微服務。而同時也是你面向你的客戶，可以更細顆粒度、更豐富類型的服務。在個過程中，我們思維可以適當的跳出並脫離IT。
講一個很有趣的應用。在德國，收發快遞沒有像中國的各個小區的快遞箱那麼的方便，如果快遞員在發你快遞的時候，你恰好不在家，這個時候快遞員就會把快遞再帶回去。遇到快遞員5點到你家，你6點下班的情況。你就悲劇了。所以，戴姆勒開展了一個名爲“Ready To Drop”與DHL一起合作的創新實驗。當你在網上購物後，你可以指定一臺SMART車作爲你的收貨地址。快遞員到了你指定的SMART車旁後，會使用一個交易編碼，通過SMART改裝後加上的硬件，使用APP把後備箱打開，然後把你購買的物品放在你指定的SMART，購物者在收取時，也就使用交易編碼就可以打開後備箱取走包裹。
信息圖片均來自 http://www.digitaltrends.com/cars/daimler-smart-ready-to-drop/
在分時租賃car-sharing、Ready To Drop中都涉及到了一點，智能硬件對於車輛的改裝，讓汽車不再需要通過鑰匙的方式被共享，而汽車本身就是一個服務。分時租賃car-sharing、Ready To Drop只是架設在VaaS(Vechile as a Service，車輛即服務) 之上的創新應用。而不管你在加裝了智能硬件的汽車上做什麼業務，將VaaS從分時租賃car-sharing的上下文中，單獨拆離出來，可以加速創新，在較低新增成本的前提下，給客戶提供多樣化的、便捷的、有趣的服務。
最近很多討論微服務的文章都提到了康威定律，組織架構會通過系統架構方式體現出來。延生一點，一個公司對外提供什麼服務，也會通過系統架構的方式體現出來。所以，微服務不僅僅是針對IT的微，提供IT的敏捷，也更是提供了公司對客戶的微，能夠服務更多的客戶，創造可能的更多的收入。
所以，我個人的原則是，當有人在問我拆微服務的時候，或者我想要拆微服務的時候，我都會問，這樣做了，可以增加更多的收入嗎？可以創造更多的可能性嗎？如果不能，我們可以乾點兒別的更加直接的賺錢嗎？聊錢似乎有點兒俗，但如果不能創造價值，本身也就只是一個觀賞品。
2. 在智能出行領域，使用微服務，可以幫公司（或客戶）減少成本嗎？如果是，是怎麼做到的？
成本的類型很多，我這裏想舉例子講的成本，更多的是指研發成本、時間成本。巨大部分公司都是已經做了，即使可能實現落地水平有差。找個年薪五六十萬的架構師定義interface，找幾個畢業一兩年的年輕人敲敲實現。說到這裏，忍不住插科打諢一句，在通信行業，有這麼一個說法，一流的公司做的是協議定製，二流的公司纔是做研發設計與製造。
在講減少成本的微服務之前，我需要做一個前提假設，這個假設對於車輛規模達到一定數量的車隊，比如千臺以上。有一些公司，比如有車企背景的公司，在開展car-sharing業務的時候，在開始往往會使用單一車型，這樣在車輛的保養、維修、運營上都可以一定程度上的節約成本，形成一定的規模效應。但是，當在某個局部地區或城市，只使用單一品牌、單一車型提供的服務，瞄準的客戶羣體本身就可能受到一定限制。如果你去瀏覽神州租車、一嗨租車、安飛士租車這些大的租賃公司，他們提供的車型往往是比較豐富的。這個時候，就會帶來一個問題，硬件供應商的問題。現在市場的情況是，硬件供應商很多，每家硬件供應商都會有自己比較擅長的車型，比如德系車或者日系車。同時，每家供應商，也都會有自己定義的通信協議。有的可能是MQTT的方式，有的是HTTP API Gateway，也有的是原生的TCP長連接。這個時候，如果當因爲公司業務發展需要，希望使用新的車型，原有的合作的硬件供應商，可能不會那麼滿足需求，而市場上又有那麼多家供應商，哪家靠譜呢？哪家的硬件質量能夠達到你期望的工業指標呢？在傳統的做法上，可能會先通過網絡搜索、調研等方式，確定一個5~10家的清單，然後分別做對接，測試。因爲考慮到車本身的複雜性，和第三方接口定義的合理性這些問題，假設一家對接需要2個人周，5~10家就需要10~20個人周，等你倒騰完，再試運營1個月。時間很快就過去了，投入了的20個人周的人力成本，也最終有效的人力成本其實只有2個人周。
那麼可以怎麼做呢？
前面提到了，如果你的車隊數量足夠大，你完全可以自己制定協議，我定義了發送鎖車指令就是比如說POST /vehicles/{id}/commands "{"type", "LOCK"}"這樣，那好了，你要來投標，你就造着我的要求來實現這樣一個接口，你自己使用的是MQTT也好、原生TCP也好，HTTP API Gateway也好，跟我沒有半毛錢關係，我不需要提供任何的研發資源，我只需要提供一個接口協議標準，一套測試環境、測試框架，和用來做第三方硬件服務註冊的功能。其他的事情就完全可以由供應商來做，研發成本、時間成本均攤到各個投標的供應商。使用微服務，就以解決這個問題，如下圖所示：
上圖中綠色的部分，可以通過我指定的標準接口，來微服務化，衆包給不同的硬件供應商。同時，我們可以針對不同大類的通信類型，提供相應的開發模板和環境，從而也加速供應商的開發節奏。比如，如果你的供應商採用的原生TCP長連接，維護鏈接，啓動服務器，基礎信息管理，他其實都不需要做。他使用我提供的原生TCP微服務模板就行了，他之需要在實現指定的接口，做二進制消息轉換就可以了。而對於平臺來說，也就是硬件的採購者來說，我需要的是提供越來越好、越來越穩定的VaaS API層，更完善的硬件GPS、網絡監控功能，形成對業務服務質量的監控，也形成對第三方硬件質量的監控（如掉線率），關注點變少，需要的人力成本、時間成本也會降低。這就是一個通過微服務來降低成本的例子。
所以，再來一次，就是，如果你拆的微服務，既不能增加收入、也不能減少成本，那麼還有沒有其他可以增加收入、減少成本可以做的事？如果是，那還是先做那個吧
3. 在智能出行領域，使用微服務，可以幫公司（或客戶）管理提效嗎？如果是，是怎麼做到的？
實在沒興趣舉例討論這個，有好些已經有的文章在討論了。
上面的觀點，想表達的更多的是，跳出IT本身、跳出IT組織架構本身來看問題，按照增加收入、減少成本、管理提效來排列優先級，更專注於業務價值的提現。