技術改造如同徒步沙漠，懷揣著對技術的嚮往開始一段征程，然過程的艱辛讓技術同學們痛並快樂著，補不完的bug，填不完的坑，但他們始終持續挑戰！
但面對微服務改造依舊會有不理解的老闆和同事們，今天小編就跟大家一起聽拍拍信技術vp裴華講課。10月22日在Spring Cloud 中國社區以主題為《進擊的微服務架構》的週年活動-上海站活動現場，拍拍信技術vp裴華進行了如下分享：
微服務改造演進的概述
微服務是業內近年業內很火的流行詞，遷移到微服務架構，大多強調這些好處：
松耦合
獨立發佈
快速迭代
故障隔離
增加重用
經過服務的拆分，將複雜到難以移動的單體應用，拆分為多個可以獨立部署的服務，單個服務的複雜性遠遠小於整體，這樣不同服務的開發者可以並行開發，從而提高開發效率；因為服務的細粒度，可以分配到具體的個人讓他負責，隨著業務的增長對服務做定向擴容；同時因為服務的隔離性，可以隔離故障，提高整體的穩定性。
但是微服務也不是萬金良藥，過渡或者不合理的拆分會造成整體系統的複雜性增加：
1-1原來簡單的本地調用都變為網絡調用，調用時效，異常處理等機制更加複雜；1-2原來一個工程可以完成的事情，需要若干個工程的協作，每增加一個工程，對應的版本管理，主幹合併等一系列工作增加，會增加維護成本，對於體系自動化的要求很高；1-3
服務依賴複雜，增加服務治理的難度。因此如何合理規劃微服務就成為了技術演進過程中重要的思考項。
另外絕大部分公司都會有不少老系統，而且這些老系統承載了公司一定的業務。在進行技術體系演進和改造的過程中，必然遇到如何兼容性的問題，拍拍信自然也是如此，在微服務演進的過程中如何支持老的非微服務系統，使得系統平穩過渡演進，支持業務發展也是重中之重。
微服務演進改造的實施過程中要點2-1
微服務改造需要實現的是整套完整體系（Spring Cloud生態體系）
服務中間件
網關係統
管理系統
監控體系
配置系統
- 發佈系統
2-2體系必須逐步迭代完善，從小到大，從簡到繁
每個階段的產出必須要能夠被呈現（難）
架構的整體改變都可能影響很大
合理切分上線功能
3-3服務切換必須不能影響業務
合理規劃設計
測試：功能、性能、異常
提前演練
拍拍信在微服務實踐路上的典型問題
3-1選型：
市面上常見的框架：dubbo/dubbox，為什麼選擇Spring Cloud？對比其他中間件，Spring Cloud的優勢有：
輕量級，和現有Spring開發體系結合緊密，學習曲線平滑；
社區生態體系完善，有足夠的開源體系可以支持或者可供二次開發和其他開源軟件整合便捷；
重點考慮：便捷、成本低、體系全！
3-2微服務和非微服務的兼容與過渡：
人：實施依靠人的驅動，因此人的因素是最重要的
思路的扭轉
學習（自驅和被動）
提升（給未來的發展鋪路）
事：從實施過渡過程來講，需要依賴以下的事情完成
中間件的支持（網關）
發佈系統支持
微服務調用和httpclient接口同時支持
當然，這樣做也導致了一些缺陷的存在，短期無法完全克服：鏈路關係沒法完全打通；記賬體系不一致。
3-3控制微服務拆分的粒度：拆分的原則不要為了拆而拆，一個工程拆成100多個子項目見過麼？不確定的可以先作為組件包，獨立出來服務的邏輯要獨立。3-4監控
要有監控的不是系統，而是生命線一樣的心態。
-
項目開發完成不是終點，產品業務能否長久生存靠監控
系統未成先想監控
監控必須確保多個維度，想得越全越靠譜
監控的維度儘可能保持一定交叉覆蓋度
拍拍信微服務實踐情況展示4-1
腳手架用來作為微服務開發的基礎組件
4-2依賴於Zuul實現拍拍信網關係統
head & query傳參
基於數據庫加載路由表信息
基於數據庫加載路由規則信息信息
入參透傳、入參轉換、json入參轉換
下游入參的groovy腳本執行支持出參的groovy腳本執行支持
出參透傳、出參映射（json映射）
用戶IP白名單
用戶調用次數限量
全局靜態URI黑名單
動態上線api、下線api
4-3完整的整體微服務管理體系
4-4監控系統
ELK用於支持原有系統和運維日誌體系
l 拍拍信監控系統
Metris業務打點
PinPoint調用監控
4-5完整的發佈系統
支持微服務和微服務
支持灰度
4-6集成Apollo配置系統
支持yml本地開發配置，服務端統一讀取Apollo配置中心
和發佈系統整合，支持配置灰度發佈
本期對微服務的分享就到這裡啦，咱們下期見，歡迎大家聯繫探討。
地址：上海市浦東新區張江丹桂路999號G1棟
感謝您對拍拍信的認可與支持
我們一直在路上
閱讀更多 拍拍信 的文章
