文章來源：InfoQ 寫作平臺，2020 年 12 月 18 日發佈
爲了實現基於微服務開發的產品，或者說爲了將單體應用重構爲微服務架構時，將面臨着衆多技術框架的選擇。大公司往往會有專門的部門或團隊來負責自主研發自己的框架，以滿足產品的需要，但是對於一般的中小型企業，選擇合適的開源框架就顯得更接地氣了。本章將簡單介紹微服務中，在技術選型時需要注意哪些原則，一些常用的開源技術框架，希望能夠爲大家在進行技術選型、調研時提供一些思路方向。
筆者面試過很多程序員，一提及微服務，就會具體說道 Spring Boot、Spring Cloud，然後就是“背誦”各種具體的用法和配置文件。並不是說這樣不對，但我們更希望知道的是這些技術框架的原理，爲什麼選擇它，它與其他類似框架又有何不同呢。
至於一個技術框架該怎麼用，它適用於什麼場景，筆者建議可以直接閱讀官方或對應的 github 上的文檔，有需要時還可以閱讀下關注點的源碼，這樣對正確的理解它，是很有必要的，畢竟官方發佈的東西是相對權威的，其他地方的資料或許存在片面性，對大家的使用、理解存在一定的誤導。(這只是筆者對大家在技術選型時，查閱資料的一些建議)
在軟件開發領域，幾乎每天都有新的技術框架誕生、更新，一些新的概念更是層出不窮，技術選型時，難免讓人無從抉擇。對於技術選型，我個人有以下幾點建議：
在微服務架構中，各類組件 / 技術很多很多，但並不意味着所有的都應該引入你的項目，倘若單純爲了覆蓋全技術棧或組件而全部引入，這將是一種很不明智的選擇。後續將會成爲你項目的累贅，讓你苦不堪言。
只要你記住這六個字：“有需求，再引入”，就 OK 了。伴隨着項目體系架構的完善、功能的健全，當有某方面的需求時，在逐步考慮是否引入某些技術組件。
“一個新項目裏最好不要使用超過 30% 的新技術”，我覺得這句話是有一定道理的。對於你完全不知道、不瞭解的技術，你是無法預估、掌控在使用過程中會出現的任何風險，一旦出現問題，短時間內解決不了，你將會變得很難堪。
在這裏不是說拒絕使用、接觸新技術，新技術是值得大家去追捧、瞭解、學習，一些新技術在很大程度上能給我們帶來前所未有的利處，解決其他技術框架解決不了的問題。這裏所說的“新技術”，是指沒有經過充分的考察、技術驗證、存在種種疑惑的技術，而是一味的拿來主義，這樣的風險可想而知。
確保選擇的技術，是業界使用最多的、被大家認可的技術，即使出現了問題，也能應對自如。至少在團隊內部小範圍是非常認可的。
GitHub 上 star 的數量是一個重要指標，同時參考近年來代碼、文檔、issues 等更新頻率，各大技術博客是否有相關技術分享記載，這些都是能夠說明該技術是否活躍、受歡迎程度、使用人羣多少等。
擁有強大社區支持的技術，在選型後，倘若使用出現疑問、問題、bug 等，能夠有地方可提、可修復、可深究探討，畢竟現在的技術社區都是足夠開放的。
慎選個人開源的技術框架、組件等，裏面到底有多少坑，沒幾個人能說清楚的，況且說不定哪天就不復存在了呢。
任何技術的出發點都是爲最終業務而服務的，不同業務、不同項目規模，對技術的要求指標都是不同的。處於初創期的業務，選型的基準是相對靈活，畢竟業務相對簡單，支撐業務不是很大，只要夠用、開發效率足夠高就好。處於複雜業務而重構的項目，選型就需謹慎，往往伴隨着一些複雜需求誕生、規模大小的不確定性，不得不考慮選型技術可能伴隨着一些小修小補或者螺旋式上升的重構，則需選型便於適配、切換、替換，耦合度低的技術。
正因爲技術選型和業務相關，我們能夠觀察到一些很明顯的現象：新技術往往被早期創業團隊或大公司的新興業務使用；中大型公司的核心業務則更傾向於用一些穩定了幾年的技術；一個公司如果長期使用一種技術，就會傾向於一直使用下去，甚至連版本都不更新的使用下去。
學會從業務端思考。首先我們需要充分地理解業務，理解用戶需求，理解當下需要解決的首要問題，以及可能的風險有哪些，再將目標進行分解，進行具體的技術選型、模型設計、架構設計。
對於未經驗證的新技術、新理念的引入一定要慎重，一定要在全方位的驗證過後，再大規模的使用，最終確定選型。新技術、新理念的出現，自然有它的誘惑，慎重並不代表保守，技術總是在不斷前進，擁抱變化本身沒有問題，但是引入不成熟的技術看似能帶來短期的收益，但是它的風險或者是後期的成本可能遠遠大於收益。
驗證後，纔有說服力，用着更放心。
每種技術架構都有其優缺點, 存在即合理, 不同的業務場景使用不同的應用架構，技術框架，不一定說最新的架構、技術就是最適合你的。
微服務架構中常提及到的主要技術框架選型如下表所示，本文後面將基於此展開說明對比。
Dubbo 是一款高性能、輕量級的開源 JAVA RPC 框架，以及 SOA 服務治理方案。簡單的說，Dubbo 就是個服務框架，說白了就是個遠程服務調用的分佈式框架。它提供了三大核心能力：面向接口的遠程方法調用、智能容錯和負載均衡、以及服務自動註冊和發現，很容易和 Spring 框架無縫集成。
Dubbo 邏輯架構如下圖所示：
Provider：暴露服務的提供方，可以通過 jar 或者容器的方式啓動服務。
Consumer：調用遠程服務的服務消費方。
Registry：服務註冊中心和發現中心。
Monitor：統計服務和調用次數，調用時間監控中心。（dubbo 的控制檯頁面中可以顯示，目前只有一個簡單版本）
Container：服務運行的容器。
遠程通訊: 提供對多種基於長連接的 NIO 框架抽象封裝（非阻塞 I/O 的通信方式，Mina/Netty/Grizzly），包括多種線程模型，序列化（Hessian2/ProtoBuf），以及“請求 - 響應”模式的信息交換方式。
集羣容錯: 提供基於接口方法的透明遠程過程調用（RPC），包括多協議支持（自定義 RPC 協議），以及軟負載均衡（Random/RoundRobin），失敗容錯（Failover/Failback），地址路由，動態配置等集羣支持。
自動發現: 基於註冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。
在現有的微服務架構下，Dubbo 只能說是一個服務治理框架，或者說是一個 RPC 框架，是以接口爲粒度，一個接口類就就是一個服務。如果直接用 Dubbo 來實現微服務架構，還缺少以下幾個功能：
分佈式配置：可以使用 Spring Cloud Config、Apollo 等來實現。
鏈路追蹤：可以使用 Zipkin、CAT 等來實現。
批量任務：可以使用噹噹網開源的 Elastic-Job 來實現。
Spring Cloud 是目前最主流的微服務架構落地首選方案之一，是基於 Spring Boot 實現的開源框架，是一個全家桶，是微服務的整體技術棧。
Spring Boot 是 Spring 的一套快速配置腳手架，使用默認大於配置的理念，用於快速開發單個微服務。
它爲服務註冊發現、動態路由、負載均衡、配置管理、消息總線、熔斷器、分佈式鏈路追蹤、大數據操作等提供了簡單的實現，讓我們可以更簡潔的使用它。
正如我們前面說過的，微服務是可以獨立部署、水平擴展、獨立訪問的服務單元，而 Spring Cloud 就是這些微服務的“大管家”，採用了微服務這種架構之後，項目的數量會非常多，調用鏈路複雜，從而管理成了很大的問題，而 Spring Cloud 框架恰恰提供了各種組件用於管理和治理微服務。理所應當的，就成了大家首選框架了。
Spring Cloud 的整體架構如下圖所示，提供一站式的微服務架構解決方案。
使用 Spring Cloud 來構建微服務架構可以省去你整合各家技術的成本，Spring Cloud 爲我們構建微服務架構提供了一站式的解決方案，就好比當初 Spring 誕生是爲解決 EJB 企業應用開發的衆多問題而提供的一站式輕量級企業應用開發解決方案一樣，隨着使用 Spring Cloud 的產品數量增加，Spring Cloud 在微服務架構中已一統江湖。
下面是 Spring Cloud 的完整技術棧，看完你就知道它爲啥會在微服務架構中一統江湖了。
通過上表對比，很容易發現 Spring Cloud 擁有很多的項目模塊，包含了微服務系統的方方面面。Dubbo 是一個非常優秀的服務治理和服務調用框架，但缺少很多功能模塊，例如網關、鏈路追蹤等。在項目模塊上，Spring Cloud 佔據着更大的優勢。對比並不是否定誰，推崇誰，只是說明在不同場景下，有利優劣，需客觀來看。
如果僅關注於服務治理的這個層面，Dubbo 其實還優於 Spring Cloud 很多：
支持多種序列化協議，如 Hessian、HTTP、WebService。
Dobbo Admin 後臺管理功能強大，提供了路由規則、動態配置、訪問控制、權重調節、均衡負載等功能。
在國內影響力比較大，中文社區文檔較爲全面。
阿里最近重啓維護，成爲 Apache 孵化項目。
Dubbo 使用 RPC 協議效率更高，在極端壓力測試下，Dubbo 的效率會高於 Spring Cloud 效率一倍多。
如果對效率有極高的要求建議使用 Dubbo，相對比 RPC 的效率會比 Restful 高很多，如果選擇微服務架構去重構整個技術體系，那麼 Spring Cloud 是當仁不讓之選，它可以說是目前最好的微服務框架沒有之一，並且可以斷言，將來 Dubbo 可以很好的整合到 Spring Cloud 中。
API 網關作爲微服務中所有服務的唯一入口，免得業界各類成熟的技術框架組件，在進行技術選型時，需要特別考慮是否擁有以下特性：
高可用：網關是對外的唯一關口，必須保證 7 * 24 小時可用，持續提供穩定可靠的服務。
高性能：所有的請求都會經過網關，它承受的壓力是巨大的，所以必須保證它具備良好的性能，以應對高併發請求。
安全性：網關必須能夠防止外部的惡意訪問，確保內部各個微服務的安全。
擴展性：網關是一個處理非業務功能的絕佳場所，必須能夠提供流量管控、協議轉發、日誌監控等服務，同時能夠爲以後對非業務功能的擴展提供良好的兼容性。
Zuul 作爲 Spring Cloud 中的核心組件之一，充當 API 網關的重要角色，所有請求都可以通過 Zuul 達到後端的應用程序、服務。Zuul 提供了動態路由、監控、彈性負載和安全等特性，其核心是一系列的 Filter，其作用類似於 Servlet 框架中的 Filter，或者 AOP。
Zuul 底層利用各種 Filter 實現瞭如下功能：
動態路由：根據需要將請求動態路由到後端集羣。
身份認證和安全性：識別每個需要認證的資源，拒絕不符合要求的請求，如：鑑權。
統計監測：在服務邊界追蹤並統計數據，提供精確的統計監測視圖。
壓力測試：逐漸增加對集羣的流量以瞭解其性能。
負載卸載：預先爲每種類型的請求分配容量，當請求超過容量時自動丟棄。
靜態資源處理：直接在邊界返回某些響應。
基於上述這些功能特性，使得 Zuul 作爲 API 網關的不二之選。
Zuul 的邏輯架構如下圖所示:
Zuul 的過濾器之間是不直接通信的，而是通過一個 RequestContext 的類來進行數據傳統，RequestContext 繼承 ConcurrentHashMap，使用 ThreadLocal 變量來記錄每個 Request 需要傳遞的數據。
Zuul 的過濾器是由 Groovy 來實現的，這些過濾器文件被存放在 Zuul Server 的特定目錄下，Zuul 會定期輪詢這些目錄，修改過的過濾器會動態加載到 Zuul Server 中，以便過濾請求使用。
Zuul 的大部分功能都是通過過濾器來實現的，其中定義了 4 種標準的過濾器類型 (pre、route、post、error)，以滿足應用於請求的不同階段。
(如果想更清晰深入的瞭解 Zuul，可以參考上圖的 Zuul 邏輯架構圖，並結合 Zuul 源碼深入研究下。)
在瞭解 traefik 之前，不妨先看看它的整體架構圖，如下所示：
從上圖不難看出，traefik 充當了 HTTP 反向代理的角色，使得發佈的服務變得輕鬆有趣。在微服務中，實質上是一個爲了讓部署微服務變得更加便捷而誕生的 HTTP 反向代理、負載均衡工具。，它支持多種後臺 (Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd, Zookeeper, BoltDB, Rest API, file…) 來自動化、動態的應用它的配置文件設置。
除了衆多功能之外，traefik 的與衆不同之處還在於它會自動發現適合您服務的配置。無需維護和同步單獨的配置文件, 一切都會自動，實時地進行（無需重新啓動，不會中斷連接）。使用 traefik 後，你可以將更多的精力、時間花費在開發和部署上面，而不是在配置和維護其工作狀態上。
高性能
無需安裝其他依賴，通過 Go 語言編寫的單一可執行文件
支持 Restful API 接口
多種後臺支持：Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd
後臺監控, 可以監聽後臺變化進而自動化應用新的配置文件設置
配置文件熱更新。（無需重啓）
正常結束 http 連接
後端斷路器
輪詢，rebalancer 負載均衡
Rest Metrics
支持最小化官方 docker 鏡像
後臺支持 SSL
前臺支持 SSL（包括 SNI）
清爽的 AngularJS 前端頁面
支持 Websocket
支持 HTTP/2
網絡錯誤重試
支持 Let’s Encrypt (自動更新 HTTPS 證書)
高可用集羣模式
OpenResty 是一個基於 Nginx 與 Lua 的高性能 Web 平臺，其內部集成了大量精良的 Lua 庫、第三方模塊以及大多數的依賴項。用於方便地搭建能夠處理超高併發、擴展性極高的動態 Web 應用、Web 服務和動態網關。
OpenResty 通過匯聚各種設計精良的 Nginx 模塊（主要由 OpenResty 團隊自主開發），從而將 Nginx 有效地變成一個強大的通用 Web 應用平臺。這樣，Web 開發人員和系統工程師可以使用 Lua 腳本語言調動 Nginx 支持的各種 C 以及 Lua 模塊，快速構造出足以勝任 10K 乃至 1000K 以上單機併發連接的高性能 Web 應用系統。
OpenResty 的目標是讓你的 Web 服務直接跑在 Nginx 服務內部，充分利用 Nginx 的非阻塞 I/O 模型，不僅僅對 HTTP 客戶端請求, 甚至於對遠程後端諸如 MySQL、PostgreSQL、Memcached 以及 Redis 等都進行一致的高性能響應。
Kong 是一個在 Nginx 中運行的 Lua 應用程序，並且可以通過 lua-nginx 模塊實現，Kong 不是用這個模塊編譯 Nginx，而是與 OpenResty 一起發佈，OpenResty 已經包含了 lua-nginx-module，OpenResty 不是 Nginx 的分支，而是一組擴展功能的模塊。
是一個 Api Gateway，通過插件的形式提供負載均衡，日誌記錄，身份驗證，速率限制，轉換等功能。可以很輕鬆擴展功能，模塊化，可以運行在任何基礎設施上。
它的核心是實現數據庫抽象，路由和插件管理，插件可以存在於單獨的代碼庫中，並且可以在幾行代碼中注入到請求生命週期的任何位置。很方便地爲路由和服務提供各種插件，網關所需要的基本特性，Kong 都如數支持：
雲原生：與平臺無關，Kong 可以從裸機運行到 Kubernetes。
動態路由：Kong 的背後是 OpenResty+Lua，所以從 OpenResty 繼承了動態路由的特性。
熔斷
健康檢查
日誌：可以記錄通過 Kong 的 HTTP，TCP，UDP 請求和響應。
鑑權：權限控制，IP 黑白名單，同樣是 OpenResty 的特性。
SSL: 可以爲基礎服務或 API 設置特定的 SSL 證書。
監控：Kong 提供了實時監控插件。
認證：如數支持 HMAC, JWT, Basic, OAuth2.0 等常用協議。
限流
REST API：通過 Rest API 進行配置管理，從繁瑣的配置文件中解放。
可用性: 天然支持分佈式。
高性能: 背靠非阻塞通信的 nginx，性能自不用說。
插件機制: 提供衆多開箱即用的插件，且有易於擴展的自定義插件接口，用戶可以使用 Lua 自行開發插件。
上面這些特性中，反覆提及了 Kong 背後的 OpenResty，實際上，使用 Kong 之後，Nginx 可以完全摒棄，因爲 Kong 的功能是 Nginx 的父集。
綜上對比，從開源社區活躍度和學習成本來看，無疑是 Zuul 和 Traefik 較好；從成熟度來看，較好的是 Kong、Traefik；從性能角度來看，Kong 要比其他幾個領先一些，從架構優勢的擴展性來看，Kong 豐富的插件，而 Zuul 是完全需要自研各類 Filter，但 Zuul 由於與 Spring Cloud 深度集成，使用度也很高。
服務註冊與發現，是一個古老的話題，當應用開始脫離單機運行和訪問時，服務註冊與發現就誕生了。目前的網絡架構是每個主機都有一個獨立的 IP 地址，那麼服務發現基本上都是通過某種方式獲取到服務所部署的 IP 地址。DNS 協議是最早將一個網絡名稱翻譯爲網絡 IP 的協議，在最初的架構選型中，DNS+LVS+Nginx 基本可以滿足所有的 RESTful 服務的發現，此時服務的 IP 列表通常配置在 Nginx 或者 LVS。後來出現了 RPC 服務，服務的上下線更加頻繁，人們開始尋求一種能夠支持動態上下線並且推送 IP 列表變化的註冊中心框架或組件。
現如今，各類服務註冊與發現的框架、組件很多 (Zookeeper、Eureka、Consul、etcd 等)，在選擇上更是眼花繚亂。在服務註冊與發現的技術選型上，我覺得我們應該還是有一定遵循原則和關注要點的。通常可從以下幾個方面出發，進行重點關注、抉擇。
數據一致性
負載均衡
健康檢查
性能與容量
易用性
集羣擴展性
用戶擴展性
配置中心
在微服務架構中，服務的數量以及配置信息的日益增多，比如各種服務器參數配置、各種數據庫訪問參數配置、各種環境下配置信息的不同、配置信息修改之後實時生效等等，傳統的配置文件方式或者將配置信息存放於數據庫中的方式已無法滿足開發人員對配置管理的要求，如：
安全性：配置跟隨源代碼保存在代碼庫中，容易造成配置泄漏。
時效性：修改配置，需要重啓服務才能生效。
侷限性：無法支持動態調整：例如日誌開關、功能開關。
在微服務架構中，使用配置中心之前，上述的問題或麻煩，你肯定也會遇到過，所以，是否引入配置中心，取決於你是否有下面的需求：
配置集中化統一管理
配置實時生效
一般完善的配置中心，都會從以下兩個方面設計出發，以發揮配置中心的作用。
1）配置實時生效
傳統的靜態配置方式要想修改某個配置只能修改之後重新發布應用，要實現動態性，可以選擇使用數據庫，通過定時輪詢訪問數據庫來感知配置的變化。輪詢頻率低感知配置變化的延時就長，輪詢頻率高，感知配置變化的延時就短，但比較損耗性能，需要在實時性和性能之間做折中。配置中心專門針對這個業務場景，兼顧實時性和一致性來管理動態配置。
2）配置管理流程
配置的權限管控、灰度發佈、版本管理、格式檢驗和安全配置等一系列的配置管理相關的特性也是配置中心不可獲取的一部分。(這也算是配置中心的高級特性作用)
Spring Cloud Config 作爲 Spring Cloud 中的一個組件，其功能開放，可開發性強，常是各類配置中心自我研發的基石。
從 Spring Cloud Config 的源碼 (spring-cloud-config-server) 中，可以看出目前支持本地存儲、Git 倉庫存儲、SVN 倉庫存儲、數據庫存儲方式，其他存儲方式可參考源碼自行實現即可。
以 Git 存儲方式爲例說明，Spring Cloud Config 包含 config-server、Git 和 Spring Cloud Bus 三大組件：
config-server 提供給客戶端獲取配置。
Git 用於存儲和修改配置。
Spring Cloud Bus 通知客戶端配置變更。
本地測試模式下，Spring Cloud Bus 和 config-server 需要部署一個節點，Git 使用 GitHub 就可以。在生產環境中，Spring Cloud Config，config-server 需要部署至少兩個節點。Spring Cloud Bus 如果使用 RabbitMQ，普通集羣模式至少需要兩個節點。
Git 服務如果使用 GitHub 就不用考慮高可用問題，如果考慮到安全性要自建 Git 私有倉庫，整體的成本比較高。Web 服務可以部署多節點支持高可用，由於 Git 有數據的一致性問題，可以通過以下的方式來支持高可用：
Git+Keepalived 冷備模式，當主 Git 掛了可以馬上切到備 Git。
Git 多節點部署，存儲使用網絡文件系統或者通過 DRBD 實現多個 Git 節點的數據同步。
Apollo（阿波羅）是攜程框架部門研發的分佈式配置中心，能夠集中化管理應用不同環境、不同集羣的配置，配置修改後能夠實時推送到應用端，並且具備規範的權限、流程治理等特性，適用於微服務配置管理場景。
Apollo 分爲 MySQL，Config Service，Admin Service，Portal 四個模塊：
MySQL：存儲 Apollo 元數據和用戶配置數據。
Config Service：提供配置的讀取、推送等功能，客戶端請求都是落到 Config Service 上。
Admin Service：提供配置的修改、發佈等功能，Portal 操作的服務就是 Admin Service。
Portal：提供給用戶配置管理界面。
本地測試 Config Service，Admin Service，Portal 三個模塊可以合併一起部署，MySQL 單獨安裝並創建需要的表結構。在生產環境使用 Apollo，Portal 可以兩個節點單獨部署，穩定性要求沒那麼高的話，Config Service 和 Admin Service 可以部署在一起，數據庫支持主備容災。
Nacos 是一個更易於構建雲原生應用的動態服務發現、配置管理和服務管理平臺。這正是 Nacos 官方給出的定義：
an easy-to-use dynamic service discovery, configuration and service management platform for building cloud native applications.
核心功能：
動態配置服務：
動態配置服務讓您能夠以中心化、外部化和動態化的方式管理所有環境的配置。動態配置消除了配置變更時重新部署應用和服務的需要。配置中心化管理讓實現無狀態服務更簡單，也讓按需彈性擴展服務更容易。
服務發現及管理：
動態服務發現對以服務爲中心的（例如微服務和雲原生）應用架構方式非常關鍵。Nacos 支持 DNS-Based 和 RPC-Based（Dubbo、gRPC）模式的服務發現。Nacos 也提供實時健康檢查，以防止將請求發往不健康的主機或服務實例。藉助 Nacos，您可以更容易地爲您的服務實現斷路器。
動態 DNS 服務：
通過支持權重路由，動態 DNS 服務能讓您輕鬆實現中間層負載均衡、更靈活的路由策略、流量控制以及簡單數據中心內網的簡單 DNS 解析服務。動態 DNS 服務還能讓您更容易地實現以 DNS 協議爲基礎的服務發現，以消除耦合到廠商私有服務發現 API 上的風險。
Nacos 部署需要 Nacos Service 和 MySQL：
Nacos Service：對外提供服務，支持配置管理和服務發現。
MySQL：提供 Nacos 的數據持久化存儲。
單機模式下，Nacos 可以使用嵌入式數據庫部署一個節點，就能啓動。如果對 MySQL 比較熟悉，想要了解整體數據流向，可以安裝 MySQL 提供給 Nacos 數據持久化服務。生產環境使用 Nacos，Nacos 服務需要至少部署三個節點，再加上 MySQL 主備。
整體來看，Nacos 的部署結構比較簡單，運維成本較低。Apollo 部署組件較多，運維成本比 Nacos 高。Spring Cloud Config 易於定製化二次開發，生產高可用的成本最高。
總的來說，Apollo 和 Nacos 相對於 Spring Cloud Config 的生態支持更廣，在配置管理流程上做的更好。Apollo 相對於 Nacos 在配置管理做的更加全面，不過使用起來也要麻煩一些。Nacos 使用起來相對比較簡潔，在對性能要求比較高的大規模場景更適合。
END
版權申明：內容來源網絡，版權歸原創者所有。除非無法確認，我們都會標明作者及出處，如有侵權煩請告知，我們會立即刪除並表示歉意。謝謝。
本文分享自微信公衆號 - JAVA高級架構（gaojijiagou）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。