大家晚上好，今天給大家分享的内容是 ppmoney 微服務之路。
首先簡單介紹一下，我是來自 ppmoney 的資深架構師 敖小劍，目前負責 ppmoney 的基礎架構和服務化推進。
今天分享的内容主要有四個部分：
首先，介紹了一下為什麼要選擇微服務架構
其次，講一下我們微服務架構的技術選型
第三，介紹微服務生态中的支撐體系
第四，舊有系統的遷移改造
我們先開始第一部分的内容：為什麼要選擇微服務架構？
先簡單介紹一下我們公司——ppmoney(萬惠).
4年做到600億元，企業可以說是 野蠻生長。在快速發展的同時，沉積的問題也很多。
大多數創業公司在初期技術上是很郁悶的，沒有足夠的技術基礎，是以早期技術棧會呈現多樣化。造成多樣化的原因，首先是“黑貓白貓，能上線就是好貓”：隻要能把代碼寫出來、能上線，就ok；第二個是怎麼快怎麼來？包括買,比如淘寶第一個版本。
問題随即暴露，規劃不足、實施艱難；需求太多，來不及規劃；變更太快，規劃跟不上；還有非技術的原因比如人員變動頻繁。整個野蠻生長的過程中，技術債務會越來越多，開發成本會越來越高。現在在加新的功能，會比想象中的要難得多。而且，最嚴重的是出現了“惡性循環”。
而對于網際網路金融企業，應對市場的速度必須要足夠快，否則難于立足。
如漫畫中所示，我們出現幾個問題：
方法不得當，開發效率非常低，
問題積累，工程師不堪重負
沒有時間改進，咬牙硬扛
即使給工程師現成的改進方案，他也會拒絕接受：我們很忙，我們沒有時間。
這是一個令人心酸的局面，雙方都很無奈。
我們改進的方向:
首先事情要規範化，讓無序的開發變成有序。無序的開發是什麼概念？逮到哪就做到哪，至于用什麼技術：有什麼人用什麼，會什麼用什麼。有序的開發有很重要的事情，叫做“統一”，同時簡化技術棧。
第二個就是要“可重用”。之前的項目都是從頭開始或者是從上一個項目裡頭複制過來，這裡面是有很多事情沒有做好的：基礎類庫、基礎設施、基礎架構。做這些最終的目标是提升大家的項目起點，所謂"不要輸在起跑線上"。
第三個是“靈活”。這個東西對我們而言做得非常不好，現在基本上是屬于沒有的狀态。雖然各個團隊都在宣稱靈活，但是實際做的不太好。
第四個就是“自動化”。這個就是我們希望能改進的一個重點，包括自動化測試、自動化部署、雲技術、容器化等，解決這個問題的最終的目标：擺脫低級重複。
devops和每日釋出是我們的最終目标，雖然從目前看差距還非常大。
我們最終的選擇是推行服務化，以微服務架構為目标進行技術轉型。
微服務的概念和好處這裡就不展開。
接下來我們開始第二部分的内容，講一下我們微服務架構的技術選型。
這是 ppmoney 自行開發的微服務架構，海豚，英文名 dolphin。希望這個架構做的靈活、輕快、優雅，就像海豚一樣。
開發工作從今年3月份剛開始，目前版本到了 0.7.*，已經線上上跑了。另外後面會提到，我們最重要的一個大系統已經基于這個架構做了重構(或者說重寫)，即将在10月上線。
我們的小目标：打造業界一流的微服務架構。
dolphin要打通整個業務的全流程，這個可能是跟其他微服務架構極為不同，這也是我們技術選型的一個重要的基石。
通常來說的微服務架構覆寫的都是伺服器端，不同的的伺服器之間的調用。但是這裡我們會有一個非常重要的需求，我們必須要把手機app覆寫到。為什麼要加這個需求？一個簡單的數字足以說明：目前80%成交額來自于手機app。是以我們除了考慮伺服器端之外，要考慮從手機app到伺服器端的資料通訊。
我們希望它能覆寫日常的開發場景，包括手機app開發、web伺服器開發、應用服務。另外要實作的一個目标就是要三位一體，也就是上面這句話，“打通開發、測試、運維三條線”，實作整個流程的暢通，最終實作全程自動化。
我們看一下dolphin的主要技術棧：
google開源的grpc架構，支援多平台多語言，最大的優點是支援手機app。
springboot，spring團隊集大成之做，口碑非常好，好用易上手。
etcd3，2016年7月1号才釋出，夠新鮮，主要用于服務發現和配置
首先介紹一下gprc。這是 google 新推出來的 rpc 架構，今年8月才釋出的 1.0 正式版。gprc 的主要特性：
protocol buffer 3.0：最重要的改進就是可以支援 ios 和 android
http/2 協定：出來有幾年了，目前正在慢慢鋪開
netty 4.1：提供nio支援和 http/2支援，也是今年6月才剛釋出的正式版本
對android/ios的支援，這對我們來說是殺手锏級的特性
gprc 的主要特性：
有兩個特性對我們來說特别的重要：
多路複用，可以全雙工發送請求和接收應答，不再需要連接配接池，即使幾萬 qps 也是可以一條 socket 搞定。
支援流/stream，在流的基礎上實作了server push，友善做變更通知，不再需要用戶端做費力的 long pull。
google 給 grpc 的地位中就明确提出：将移動和http/2 放在首位。剛好契合我們的需求，是以成為我們dolphin微服務架構中最重要的一個技術選型目标。
我們選擇了 spring boot 作為微服務架構的基石，這也是業界常見做法。暫時沒有選擇 spring cloud，主要是技術選項和我們差異比較大。
在3月份我們做技術選項時，在 zookeeper，etcd， consul 之間我們最後選擇了 consul。但是在7月1日 etcd 的 3.0 版本釋出之後，我們決定将 consul 替換為 etcd 3.0。
因為我們覺得 etcd3 更适合 dolophin 架構。注意我說的是更适合，不是說 etcd3 更好。
使用 etcd3 替代 consul 的幾個理由：
統一通訊協定：新釋出的 etcd3 給了我們一個很大的驚喜：它的通訊機制改了，etcd3 改用 grpc 作為通訊機制，替代原有的rest。因為 dolphin 架構也是使用 grpc，是以改用 etcd3 替代 consul 之後就簡化了内部通訊機制，都統一為 grpc 了。
減少依賴：不用 consul 之後進而也省掉了 consul client 端引入的一大堆的用來實作 rest 和 long pull 的依賴包
性能提升：這個容易了解，grpc 是二進制格式，對 rest 明顯速度肯定是優勢
更高效的推送機制：基于http/2 stream 的伺服器端推送機制，效率比基于 long pull 的高，考慮到除了服務發現之後，未來還要做配置變更的通知，而且配置項的數量遠遠超過服務的數量，這個帶來的提升會更大。
這是目前的開發路線圖，包括 dolphin 架構外圍的一些基礎設施，我們預計在年底前能完成微服務架構必備的大部分基礎功能。
現在開始這次分享的第三部分，介紹微服務生态中的支撐體系。
首先給大部分正在推行微服務和想推行微服務的同學，潑一盤涼水 :)
不是有了微服務架構就足夠的
把架構做好之後，是不是就可以簡單的可以在一家公司裡推行微服務？我遺憾地告訴大家，這個沒有什麼必然的關系，并不是你有了微服務的架構，就可以把後面的事情做好。用數學的術語說，微服務架構隻是一個 必要不充分 條件。
微服務不是銀彈，不能指望微服務單槍匹馬的解決問題，“隻要微服務一出來，就輕輕松松搞定。” 這種想法不現實。
左邊是幻想，右邊是現實。
微服務架構需要一系列的基礎設施，作為整個微服務體系的基石。
這裡面有些是微服務架構的标配，比如實作中央化配置管理的配置中心，管理服務實施服務治理的服務中心。有些是完全和微服務架構沒有直接聯系，但是又是微服務架構必備的，比如apm/應用性能監控，日志管理如elk套件等。
在上述的基礎上，還需要進一步完善整個生态體系，比如以服務的方式直接提供部分通用功能。
圖中是我們在實施中的一些實際例子：
我們在 dolphin 架構中内置加密服務，限流服務，配合實作架構的基本功能。
鑒權服務，統一的短信網關，驗證碼服務等，這些實際和架構就沒有直接關系了，而是作為通用業務平台的一部分
對于 微服務 和 docker，隻能用天作之合來形容。
docker 這塊我們現在涉獵的不多，暫時還處于探索階段，後面微服務架構基本成型之後肯定要繼續鋪開的。
在第三部分的最後，我們總結一下實施微服務的四個要點。在微服務的實施的過程中，要真正的要把微服務做好，必須認真考量這些的足以決定成敗的因素：
靈活開發
靈活是必備的，如果是靈活都沒有做到，微服務真的是“連爬都還不會就想跑”。有時候微服務一上手發現不合适了，做這個東西之前先自問一下，靈活開發是不是跑起來了，團隊是不是用靈活的方式做開發？
組織決定架構
規劃一個技術架構或者是技術路線的時候，需要考慮組織架構是不是和技術架構比對。如康威定律所說，“組織決定架構”。為了實作服務化，你必須要讓你的組織結構做出相應的調整。需要組建跨功能的團隊，這個團隊一定不是單純的隻有開發、隻有測試、隻有運維，或者是隻有産品，這些功能應該都在你的團隊裡頭。最重要的是要減少部門牆帶來的溝通成本。這個牆是非常可怕的一件事情，它可以讓一個小時能做的東西，一個星期都做不完。
建議微服務團隊按照業務而不是按照技術來劃分組織，必須要想辦法在一個團隊内全棧，讓團隊自治。這個是我們現在試圖想做的，但坦白說這個事情很難,有時甚至是絕望。
産品的思維
一定是産品，一定不要是項目。
産品跟項目有不同？項目是做完就項目交接，團隊解散，各找各媽！産品是什麼概念？這個産品是你的，你要上線，你要維護，你挖的每一個坑都會以把自己坑進去。這是一個決定責任感的事情，做産品你要吃自己的狗糧，和做項目有質的差異，這個是非常重要的事情。
團隊
所有的問題，最終都會歸根到人的問題。為了玩的轉微服務，你得打造一支能滿足高要求的團隊，這個要求是真的比較高：産品，設計、開發 、測試都要搞得定，可能是三五個人，甚至七八個人，要一個團隊啃下産品線，包括前端、後端、測試、運維和産品。
對大多數公司來說，這四個要點完全做到還是挺難的。前面我們提到的服務化架構，各種技術選型，各種配套的基礎設施，都是硬性條件，都是技術性的支撐。而這四點，則更多的是在人文條件方面提出的要求。
下面我們開始最後一個部分的分享，談一下我們最近的一個實際例子，在這個例子中我們是如何改造我們的一個app架構和團隊，來實作微服務在實際産品中的落地。
這是我們的ppmoney理财app(也就是前面說的80%營收的核心産品)，原有的架構足夠簡單而原始：
app和伺服器背景是常見的restful
中間是一個巨型的伺服器背景程式：很要命，因為所有代碼都堆在一個war中
底層還好，一些基本功能被封裝成soa，難得。但是，用的語言是.net，然後通訊機制是以慢著稱的soap
改造的第一個階段，我們的目标是引入dolphin架構和實作基本的服務拆分：
首先app和伺服器端改用grpc
引入 api gateway來負責網絡接入，然後按照業務邏輯進行服務編排，必要時在api gateway中可以使用緩存
将原有的war按照業務邊界拆分為若幹個服務，每個服務有自己的資料存儲，緩存
某些服務可能隻是對soa接口做一個轉發和封裝彙總
這個工作我們目前基本完成，預計測試通過之後，10月份我們就會上線，逐漸替代原有的app和背景。完成之後系統的性能瓶頸可以得到極大緩解，部署彈性大為增強。
改造的第二個階段，目标是将現有.net的soa用java改寫，讓前面拆分出來的微服務變成完整的标準微服務。
這個工作還沒有開始，坦白說這個工作量比第一階段要複雜的多，soa中負責的業務邏輯，互相關聯調用的子產品耦合，一個又一個的關聯查詢，挑戰極大。
我們再讨論一下人員和團隊的問題，好的團隊從來不是天上掉下來的，是以如何打造團隊成為重點。
在這裡我們的做法是這樣，分兩步：
把架構部門打造成高素質的靈活團隊
這個是必須的，這個如果做不到，後面沒得玩。
然後再孵化滿足要求的新型業務開發團隊
這個地方有一個很逗的詞，孵化。為什麼是孵化呢？因為很多時候情況下，即使你做到了第一步，你也僅僅是有一支架構部門的團隊，而且也不可能滿足整個公司業務各個産品線的需要的，你還要把整個的業務線的開發團隊提升上來。
如何做到這一點很重要，要想辦法自己去培養、改造業務團隊。我們稱之為“孵化”，就是帶領一支業務團隊，跟他一起去做業務改造，在改造的過程中，順帶将新的團隊帶起來。過程感覺就像孵小雞一樣，需要耐心，需要投入，新的團隊開始很弱小，但是未來的成長值得期待和投入。
這裡依然要繼續給大家潑涼水，理想和現實之間的差距，往往是遠超事前的想象。
下面我們以過來人的角度(其實也隻是才上路)，給大家分析一下微服務推進的實際道路中常見的問題和難點。
計劃一開始都是很美好，但是在實施前，請先自問一個問題：資金、技術、專家，這三者是否已經齊備？
這裡有個很有意思的故事：就在今年，習總書記通路英國的時候，英國bbc記者問“英企能否在中國投資建設核電站”，中國駐英大使劉曉明反問：你們有資金嗎？你們有技術嗎？你們有專家嗎？
我們為什麼要提這個話題呢？因為一個公司要真正的提升上去，也要問一下自己有沒有這三個要素：
第一個是資金，你要組建團隊，要在整個公司推廣，把所有的流程都走通，投入巨大；
第二個是技術：前面我們羅列了一堆
第三個是專家：尤其是在業務團隊，尤其是中小公司，一般業務團隊隻有一兩個核心開發人員，有時甚至一個都微服務的都沒有，更惡劣時，連一個有基本架構設計基礎和子產品理念的都沒有
特别強調：第三點尤其緻命，而且通常都是被高層忽略或者不認可，後者帶來的問題更加麻煩。
注意，雖然說微服務不是銀彈，但微服務真是一個大炸彈！
微服務所帶來的變革是巨大的，當推行服務化，推廣微服務架構的時候，遠不是簡單的微服務架構的技術推廣問題。這個事情遠比用mongo替代mysql要嚴重的多。推廣微服務，往往是在實際上推翻整個公司的開發流程。
微服務是真正意義上的颠覆性變革，或者用另外一個詞會更準确：革命！
要推行微服務，要把這些東西通通跑通，而且做順、做好，你的微服務架構才能真正落到實處。如果有一個卡住，就會發現經被念歪了，或者走路的時候感覺是腿瘸了一般。
再一次重申康威定律！
對于任何一個試圖推行微服務的架構師而言，康威定律是一道繞不開的檻。如果沒有高層強力支援并願意為此調整組織結構，就必然在這裡遇到無法逾越的阻礙。
這個畫面絕不是隻會出現在漫畫中...... 請做好心理準備。
謝謝大家參與今天的分享，我們的内容到這裡結束，謝謝大家！
最後澄清一下：在之前的分享中曾經介紹了我們的開源計劃，原定是在2016年底在 github 開源。
但是，最近有些意料之外的變動，開源計劃預計短期之内難于實施。雖然不排除未來開源的可能，但是至少短期之内是無法如我期待的和大家見面了。對此個人深表遺憾，也萬分抱歉，請大家諒解......
問題1：微服務和服務化的關系是什麼？
服務化是微服務的超集，服務化在很早之前就提出并推行，典型如soa。而微服務是最近才興起，和服務化的最大差異在于微服務明确的在服務化的基礎上将粒度調整為不能再小的"微"，同時明确提出必須做到兩點：1. 獨立程序 2. 資料分離
問題2: 服務治理應該包含那些内容，現在有那些工具可以用？
問題3: 請比較一下各技術堆棧，如果搭建微服務，最佳工具是哪些？
這兩個問題都比較大，不是三言兩語能闡述清楚，每個話題都夠再來開一兩回今天的演講 ~0~
比較巧的是，在10月15日的中生代線下活動中，我會帶來一個新的演講，主題是如何利用開源社群來搭建微服務系統，屆時會有詳細的介紹和讨論，歡迎關注。
問題4： 使用微服務後，業務接入有沒有量化資料，說明效率提升？
暫時還沒有量化資料，因為我們最大的系統還沒有正式上線。隻能給出一個比較有意思的數字：在過去的兩個半月中，我們正在加班加點的進行前面分享的這個app背景系統的重構，标準的996加班方式,然後目前測試中，全程我們将bug控制在個位數，速度和品質都非常理想。
問題5：這個服務化架構的性能怎樣？系統測試過嗎？
簡單測試過，伺服器端空實作在普通i5主機上跑大概能有14w的 qps。一些典型的簡單業務場景，如簡單通路一兩次redis，大概幾萬 qps。不過現在還沒有時間進行深入的性能優化。
問題6：請問如何通過設計提高代碼品質
在微服務這個話題中，通過微服務的理念，将系統拆分為小的粒度，開發團隊也跟随系統拆分為小的團隊，開發人員可以集中在小型的系統中，這本身使得開發人員容易把握全局。簡單歸納為，大事化小，分而治之。
問題7：謝謝老師的分享，本人最近也在看 spring boot，java做服務動辄幾百兆，我想了解一下貴司選擇它是否有更深的原因
在分享中有給出來，你可以回頭翻到那頁ppt，理由都列出來了。個人對 spring boot 非常認可，使用友善，而且會 spring 的人也多。
問題8：1.前面講到的規範化，可重用，真靈活，自動化也是架構師在推嗎？2.你對docker什麼看法？
是的，也是我們基礎架構部門在力推。2. 我對docker很認同，和微服務簡直是絕配，下一步必然要上docker的。
問題9：grpc 沒有服務治理的部分 這部分你們有什麼好的實踐嘛？
grpc 有 name resolver，我們用來實作基于 etcd3 的服務注冊和服務發現。另外 grpc 内建了負載均衡的支援，1.0版本之後基本可以拿來用了。我們最早在 0.10版本的時候這兩個元件都不完善，我們放棄了他們自己實作了，但是1.0之後現在打算換回 grpc 自己的實作。其他的服務治理功能，打算自己動手，當然如果開源社群有合适的元件，我們會在評估之後直接拿來用。
問題10：你上馬那麼多技術，都是新技術，有沒有考慮過這些技術的更新給你帶來的影響？
這是一個非常尖銳的問題。坦白說，在今年三月我決定選擇自己搭建微服務架構，而不是繼續dobbo，然後又選擇了grpc/consul(後來換成etcd3)等新技術時，風險是非常大的。當時這幾個項目都還是beta甚至alpha狀态，我們比較幸運的時在最近幾個月，grpc 1.0/netty 4.1/protocol buffer 3.0/etcd 3.0，這幾個最重要的技術棧都陸續正式釋出，而我們最大的重構項目10月才上線。有種很幸運的感覺。
問題11： etcd3是做什麼的，感覺沒怎麼用過，使用場景是什麼和dubbo+zookeeper相比有什麼不同
etcd 和 zookeeper 類似，都是實作分布式的一緻性，不過 etcd 底層是 raft 協定，稍微簡單一些。
etcd 3.0 是 etcd 最新的版本，因為通訊協定從rest換成了grpc，是以我們在最後時刻選擇了它。
問題12：“通常來說的微服務架構覆寫的都是伺服器端，不同的的伺服器之間的調用。但是這裡我們會有一個非常重要的需求，我們必須要把手機app覆寫到。” 為什麼要加這個需求？ 請問一下這個怎麼了解？架構層面做了些什麼呢？
不是要加這個需求，而是我們本來就有這個需求。分享中我們給出了一個數字，80%，這是我們手機app端占我們總的業務量的比例。是以我們在選型時，特别認同google對grpc的定位和要求。架構層面自然是以grpc為主要通訊協定，統一了app端到伺服器端，和伺服器端内部之間的通訊，由于etcd3的緣故，現在服務注冊和配置管理也是統一為grpc了，這算是個意外，令人高興的意外。
問題13：微服務的粒度怎麼劃分，能結合業務場景簡要說明下嗎？
這個問題還是太大，有機會單獨再出一個專題來讨論和分享。坦白說，現在我們自己也是在摸索，在實踐中調整。
問題14：“底層還好，一些基本功能被封裝成soa，難得。但是，用的語言是.net，然後通訊機制是以慢著稱的soap”，soap的性能雖然很低，但是可以提供企業級的安全特性，而且支援原子事務，這方面在網際網路金融的應用場景下是怎麼考慮的？
實際中我們現在的老系統，soap的這些特性都沒有使用上。關于安全，我們會使用标準的ssl加密，這個grpc有支援，然後我們會搭建自己的鑒權服務。事務方面，現在主要還是盡量用資料庫事務做強一緻性，或者事後補償來實作最終一緻性。這塊我們目前還沒有形成足夠完善的機制，後續努力中。如有所得，再來和大家讨論。
問題15：微服務的力度如何把控，拆分過細會影響性能
這個問題和前面的問題13類似，以後再細聊。的确在度的把握上，有很多講究，需要權衡很多因素，除了業務邊界和領域模型之後，性能，事務，安全都是需要考慮的。
問題16：用thrift如何？
我們選擇 grpc 的一個重要因素是因為 grpc 支援 android 和 ios，這是決定性的因素。另外 grpc 基于 http/2 實作的 流 也是一大殺手锏，做伺服器端推送優勢太明顯。再有就是不再需要多個連接配接和連接配接池，也簡化了很多問題。thrift 理論上性能要稍微高一些，不過 grpc 也足夠用了。
最後做一下廣告， dolphin 架構使用了很多目前業界最新(絕不誇張，都是2016年才release)的技術棧，很多技術基本都沒有中文資料，是以我自己寫了一些學習筆記，裡面翻譯了部分官方的英文文檔，如果感興趣可以一起研究：
grpc學習筆記： https://skyao.gitbooks.io/leaning-grpc/
protocol buffer 3學習筆記：https://skyao.gitbooks.io/leaning-proto3/
etcd3學習筆記：https://skyao.gitbooks.io/leaning-etcd3/
consul學習筆記：https://skyao.gitbooks.io/leaning-consul/
分享者簡介：
敖小劍，ppmoney資深架構師，14年軟體開發經驗，對靈活開發，架構設計有深入研究，曾在亞信，愛立信，唯品會任職。現任ppmoney基礎架構負責人，負責dolphin微服務架構和配套基礎設施的開發，推進公司全面服務化。
本文轉載自微信公衆号 中生代技術 freshmantechnology