唯品會自研微服務框架OSP，解決一系列拆分、擴容難題

馬爾文·康威 1967 年提出康威定律："設計系統的架構受制於產生這些設計的組織的溝通結構。"

根據康威定律，當互聯網公司業務和團隊發展到一定規模，微服務架構是一種必然的演化趨勢。近幾年，隨著電商業務的快速發展，唯品會逐漸實施了微服務架構，面對如此大規模的電商業務，如何進行微服務框架體系的建設；面對電商大促，如何快速大規模擴容；面對如此複雜的電商業務，如何更好的拆分微服務，都是要解決的一系列難題。

7 月 14 日，唯品會企業應用架構部架構師楊欽民老師將分享唯品會微服務基礎中台和最佳實踐的演講，我們提前邀請楊老師對分享內容進行預熱解讀，希望對你 / 團隊有幫助。

1

唯品會微服務基礎中台架構設計思路

圍繞微服務，唯品會自主研發了微服務框架以及一系列配套的系統：

OSP（開放服務平台）微服務框架，提供高性能、高可擴展的遠程調用機制，實現了契約化多語言服務介面，同時提供了強大的服務化治理能力，可以實現負載均衡、路由選擇以及自我保護等。

Service Center 統一的服務治理中心，對基礎服務化項目提供的服務進行治理，將所有服務化項目的配置集中在一起，實現一處配置、多處運行的目標。

Mercury 全鏈路跟蹤監控平台，實現了全鏈路調用鏈跟蹤、指標統計、監控告警等，通過 Mercury，應用管理人員 / 架構師等可以全方位把握應用整體拓撲結構、定位全網應用瓶頸。應用開發人員可以定位線上服務性能瓶頸、持續優化代碼和 SQL、幫助快速解決線上問題，IT 運維 / 監控人員可以快速故障告警和進行問題定位、把握應用性能和容聯評估、提供可追溯的性能數據。

Janus 服務網關，為業務服務提供統一對外的、高性能的 HTTP 網關，針對外網支持 HTTPS、HTTP2、HTTP、自定義協議等，針對內網可以自動適配到 OSP 協議。

Salus 服務安全管理平台，面向 OSP 和 RESTful 形式的服務，提供服務安全管理（認證、鑒權、防篡改）的手段。

基礎中間件，CfgCenter 應用配置中心實現應用配置管理，Saturn 分散式任務調度平台具備高可用以及分片並發處理能力等，Asgard 一站式存儲服務平台可以實現統一管理、統一監控存儲服務，VMS 消息系統具備組內廣播、消息回溯、消息延時、灰度消息等。

2

唯品會開發微服務框架 OSP，和 Service Mesh 有哪些異同？

唯品會在設計 OSP 微服務框架之初，就已經單獨抽出了代理層 Proxy，類似 Service Mesh 的 Sidecar。客戶端與微服務框架代理層 Proxy 部署在同一機器的不同進程，各自獨立部署，服務治理邏輯從客戶端業務邏輯中解耦出來。

和 Service Mesh 相比，OSP 所具備的優勢包括：

加強運維管理，運維人員可以單獨針對 Proxy 進行獨立升級、維護，極大加強運維管理能力。

框架可以持續演進，Proxy 作為一個獨立的代理層，與服務隔離，並且獨立部署和運維，每次框架發布新版本時，無需業務研發部門介入，運維就能獨立進行升級和部署，因此服務框架可以持續進行演進。

支持多語言，Proxy 採用自己的開發語言進行開發，獨立演進，而每個服務均可以採用合適的開發語言，二者互不影響。

3

唯品會拆分微服務過程中遇到的難題

在拆分複雜電商業務系統的過程中，遇到的難題包括：

如何按照組織架構劃分以及搭建比較清晰的系統架構，如同康威定律所說：組織架構等同於系統架構，一個好的系統架構需要匹配組織架構，同時組織架構在很大程度上會影響系統架構的走向。

如何界定服務邊界，將複雜電商業務拆分成不同的服務時，首先面臨的是如何可以清晰的界定不同服務的邊界，減少服務間的耦合，其次面臨的是服務拆分的粒度，粒度過粗可能會造成服務間的耦合，粒度過細可能會拆分出過多的服務。

如何進行服務聚合，服務拆分之後，當面臨複雜業務時，需要考慮多個服務的聚合，是由一個團隊進行聚合分別提供各方，還是由各業務方分別聚合。

4

在微服務框架體系建設實踐中，選擇開源還是自研？

在建設微服務框架體系建設過程中，針對不同業務體量、不同技術儲備的公司，我們需要思考以下幾個關鍵點：

是選擇開源微服務框架，還是選擇自研微服務框架？如果一些大公司業務體量非常大，技術儲備非常多，發展到一定的階段，可以根據公司自身情況，考慮自研發微服務框架體系。而中小型初創公司，由於業務體量不是很大，同時技術儲備也比較少，技術人員的技術實力也不夠深厚，建議選擇各種開源微服務框架，構建自己公司的微服務框架體系。

是否選擇自構建 Kubernetes 集群。同樣，對於有自建伺服器機房且業務體量龐大的公司，選擇自建 Kubernetes 集群是再好不過了。而針對中小型初創公司，建議選擇雲服務商，可以更快構建 Kubernetes 集群。

是否選擇 Service Mesh 框架。Service Mesh 是近兩年的熱點，是否選擇跟風演進到 Service Mesh 框架，也是一個考量。大公司甚至大集團，業務線非常多，技術體系也比較豐富，一般會有多種開發語言並存，同時大公司的技術實力也非常雄厚，此時建議演進到 Service Mesh 框架，國內已經有多家有實力的大公司在積極自研發 Service Mesh 框架。而針對中小公司、初創公司，需要根據自身客觀情況考慮，一般都是只有一種開發語言，所以針對此種情況，建議可以選擇 Spring Cloud 框架、Dubbo 框架等。

5

2019 年 Kubernetes 在應用開發和運維上有非常重要的能力透出，在唯品會有哪些深入應用？

唯品會基於 Kubernetes Docker 技術框架研發了 Noah 雲平台，涵蓋應用的開發、交付、運維和運營全生命周期，整個平台包括主機層、容器層、雲平台層、鏡像管理、CI/CD，支持灰度分批發布、容器 Auto Scaling、集群節點管理、多集群時間監控等。

開發階段提供 CI 鏡像流水線，本地開發 DockerVM，功能測試環境、聯調測試環境給開發和 QA 完成鏡像的發布；

生產階段提供容器發布、容器調度、容器服務註冊發現、容器網路互通、集群管理等功能完成運維工作；

提供容器的運行時日誌、監控、告警等功能做業務監控。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！