從0到1組建架構團隊，主導並推動集團業務系統從單體應用架構向微服務架構演變，從PHP技術棧向Java技術棧轉型，從私有云向混合雲進化，並開始新一代同城多活技術架構研發與落地。作爲樂信架構總監，康彬親身實踐了一家創業公司逐步發展壯大的全部過程，可能會遇到的所有技術問題，以及爲解決這些問題而進行的架構演進。
過去幾年，架構領域最火的方向之一莫過於微服務。實踐微服務的好處顯而易見，比如其本身所具備的可擴展性、易維護性、獨立自治、故障和資源隔離等諸多特性，可以大大提高產品研發效率。同時，基於微服務架構設計風格，研發人員可以構建原生對“雲”具備超高友好度的系統，讓產品的持續集成與發佈更爲便捷，也爲後續擁抱“雲原生”打下了堅實的基礎。
但是，在計算機的世界中，沒有哪項技術可以大一統地解決所有問題，微服務同樣如此。被認爲是十大軟件架構師之一的Chris Richardson曾一針見血地指出:“微服務應用是分佈式系統，由此會帶來固有的複雜性。開發者需要在RPC或者消息傳遞之間選擇並完成進程間的通訊機制。此外，他們必須寫代碼來處理消息傳遞中速度過慢或者不可用等局部失效問題。”
在組織的業務系統向微服務架構演變的過程中，存在很多問題需要解決，比如進行微服務的時間點；按照組織架構合理拆分和容量規劃的方法；應對大規模瞬時流量的衝擊以及比較理想的實施路徑等。在ArchSummit 全球架構師峯會（深圳站）2019 大會期間，InfoQ有幸採訪到樂信架構總監康彬，探討他從0到1進行團隊搭建並主導推動多輪系統架構演變的親身經驗。
從0到1的架構演變歷程
最開始的兩年基本每天都在救火，因爲會遇到各種新問題，可能是因爲基礎技術產品缺失，也可能是已有基礎技術產品存在缺陷，或者業務研發同學使用不當等。總之，每天都在解決各種問題，被各種問題驅動向前不斷迭代。
樂信是一家互聯網金融科技服務商，集團旗下主要業務包括品質分期購物平臺分期樂商城、網絡借貸信息中介服務平臺桔子理財以及金融資產開放平臺鼎盛資產等。回顧整個架構搭建過程，康彬表示，樂信的技術架構演變主線非常清晰，但在當時團隊人員只知道大致方向，並沒有具體規劃到每一步，更多是由問題驅動逐步演化至今。
一直以來，康彬始終認爲不管是單體應用架構還是微服務架構，都只是一種技術體系，沒有好壞之分，只有是否合適。樂信的系統架構經歷了PHP單體應用架構、PHP服務化、Java服務化、混合雲、單元化和同城雙活幾個階段。雖然每個階段解決的具體問題不一樣，但這些問題本質都上都是業務持續爆發性增長帶來的技術新挑戰。
創業初期，驗證業務的可行性非常重要，PHP的便捷性是當時樂信合適的選擇。康彬透露，直到現在，樂信內部依舊有系統在使用PHP技術棧，主要是一些對高可用性要求不高或變化較快的系統，比如OA系統。
隨後，樂信對系統進行了微服務改造，如上圖，最底層是由運維團隊提供的各種資源，包括計算資源、存儲資源、網絡資源等。中間件層主要分爲微服務框架、消息中間件以及Job調度系統三部分。其中，微服務框架解決的是同步調用問題，消息中間件解決的是異步調用問題，調度系統解決的是後臺計算邏輯，比如風控處理等問題，其上承接兩大平臺——核心交易平臺和風控審覈平臺，共同提供了獲客、授信、下單以及還款等基礎中臺能力，這些基礎中臺能力支撐着上層各種前臺業務的快速發展。
但是，如果遇到大促，系統還是存在一些問題需要解決，比如機器準備週期長、緊急情況無法應對；大促後機器閒置率高，資源浪費巨大。因此，樂信開始探索混合雲架構，將流量大戶置於公有云之上，保證機器資源按需申請；接入層按URL調度流量；服務層Set化的路由策略；數據層讀請求上雲，寫請求回自建IDC。
即便這套架構足以滿足當下需求，但混合雲從物理層面來看是兩個機房，邏輯上還是一個集羣，因爲樂信內部的雲機房和本地機房共用一套註冊中心。隨着流量越來越大，集羣規模越來越大，單集羣模式如何應對？如果發生機房級的災難，單機房怎麼辦?
基於上述擔憂，樂信研發團隊又開始探索同城雙活的解決方案，在接入層建立起用戶維度的流量調度能力；統一集團Job調度平臺、分離service和job；跨機房的統一配置中心；mq具備單元化路由及容災能力；統一開放網關建設，劃清業務板塊邊界；全鏈路系統診斷能力建設完成後，樂信的混合雲&同城雙活方案基本搭建完畢。
從最開始的PHP服務化1.0階段解決單體應用架構的問題，到後來的Java服務化2.0階段解決PHP技術棧繼續演進遇到的困境，再到解決大促痛點的混合雲，以及解決跨機房容災的單元化和同城雙活方案。在這個過程中，樂信內部逐漸衍生出發佈系統、監控告警系統、全鏈路診斷系統等DevOps相關係統，消息中間件、配置中心、定時任務調度中心、分佈式文件存儲系統等微服務架構必備的相關基礎技術產品，以及針對微服務架構的開發測試解決方案穩態環境及配套的開發測試流程及工具。最終，這些組成了現在樂信的底層基礎技術平臺。
如今，樂信完成了接入層、服務層、中間件層的單元化和同城雙活能力，數據層雖然也有對應的跨機房容災，但本質上數據層還是一箇中心，在同一個城市或者兩個距離很近的城市，比如廣州和深圳，一些對跨機房延遲不太敏感的業務還可以滿足。未來，如果想做到相距千里之外的異地多活，數據單元化是一個繞不開的問題。另一方面，樂信的混合雲雖然已經可以應付各種大促，但過程中還是需要投入較多人力做壓測、容量評估、擴容、縮容等重複性工作，未來有望藉助全鏈路診斷體系和自動化性能評估體系逐步自動化完成，做到一鍵彈性擴縮容或自動化擴縮容。
微服務實踐心得
如開篇所言，微服務的好處已經被總結過很多次，比如分而治之降低系統複雜度和耦合度，各服務獨立開發部署利於團隊閉環、也有利於並行開發提高生產力，這些好處背後隱藏的是一系列複雜變化，這時就需要一系列支持體系來解決這些問題，包括開發、測試、部署、線上運維、線上故障定位及業務架構分析等。
在過往四年的微服務改造過程中，樂信曾經有一段時間爆發過開發測試環境問題。康彬透露，當時，開發人員在環境上花費的時間超過寫代碼的時間，測試人員在環境上消耗的時間超過測試時間，運維人員更加痛苦，有多少並行需求就需要維護多少套獨立開發測試環境，這些就是爲了獲取微服務的好處而付出的代價。
因此，康彬認爲是否採用微服務要根據實際的業務情況決定，考慮原有的單體應用架構體系是否確實無法支撐業務持續爆發性增長。經過各方面綜合分析後，如果企業認爲必須走微服務這條道路，那就需要考慮如下四個因素：
1、架構團隊的技術儲備是否有能力在代碼層面對微服務所依賴的各種框架、中間件進行把控；
2、基於微服務架構的各種流程規範、包括底層技術產品的使用規範、開發測試流程規範、發佈規範以及對應的檢測機制等是否已經準備好；
3、相應的DevOps體系是否開始規劃，包括CMDB系統、發佈系統、監控告警系統、全鏈路診斷系統等；
4、業務研發團隊是否準備好，包括組織架構轉變、研發流程的轉變、開發方法及習慣的轉變、所有這些都需要長期培訓及技術支持來確保有序進行。
當研發人員習慣微服務架構體系下的研發方式後，開發一個服務就變得非常簡單。所以，大部分人會選擇開發獨立的新服務來滿足各種業務需求，帶來的後果就是服務和接口數目持續增長，各業務板塊之間的邊界越來越模糊，複雜性和成本遠遠超出預期。樂信及時意識到這個問題，開始推進業務架構整改，包括梳理並下線歷史遺留的無效系統，分析單次用戶Http請求對應的後臺RPC調用層次和總數的合理性，解除業務板塊間不合理的耦合，以此推動關聯性較大的小服務的合併，沉澱各業務版本都需要的公共服務，逐步形成資源層、中間件層、核心交易和風控兩大平臺，以此支撐上面的具體業務，走的是大中臺、小前臺的路線，這也是康彬目前比較推薦的方式。
至於微服務容量規劃，康彬坦言這確實是一個痛點。樂信對這個問題的解決方式也在持續進行中。目前，康彬比較推薦的方式是單體和整體綜合治理的方式，單體就是針對單個服務、單個接口性能測試常態化，以此來掌握各個單體的性能趨勢，線下壓測是個常見的方法，如果能在線上實現自動化性能壓測，那麼測試數據更接近真實情況，對容量預估的幫助也更大。整體可以分爲單個URL下各關聯服務的整體性能壓測、以及多個URL組成的單元整體對外性能壓測，要實現這個需要各種中間件支持，類似阿里的全鏈路壓測方案，這個實現成本比較大，在業務規模增長到一定程度後再進行更加合適。
結束語
每家企業都有不同的業務狀態，實施路徑還是要根據具體情況來定，康彬在採訪最後表示，推進過程可能需要隨時根據情況變化進行調整，沒有大一統的實施路徑，但技術能力儲備、規範流程建設、配套DevOps體系搭建、組織架構以及研發方法的持續優化等依舊是需要關注的重點。
嘉賓介紹
康彬，擁有14年技術研發及管理經驗，參與/主導的研發項目涉及嵌入式開發、移動開發、後臺開發、系統架構等方面，先後任職過富士康、華爲、騰訊、阿里巴巴。近幾年主要專注在微服務架構方面的研發和管理工作，從0到1組建了樂信架構團隊，主導並推動了樂信集團業務系統從單體應用架構向微服務架構的演變、從 PHP 技術棧向 Java 技術棧的轉型，從私有云向混合雲的進化，及新一代的同城多活技術架構的研發與落地工作。