微服務(wù)下的數(shù)據(jù)架構(gòu)

-? ? ?前言? ? -

微服務(wù)是一個軟件架構(gòu)模式，對微服務(wù)的討論大多集中在容器或其他技術(shù)是否能很好的實施微服務(wù)，而本文將從以下幾個角度來和大家分享在微服務(wù)架構(gòu)下進(jìn)行數(shù)據(jù)設(shè)計需要關(guān)注的地方，旨在幫助大家在構(gòu)建微服務(wù)架構(gòu)時，提供一個從數(shù)據(jù)方面的視角：

• 微服務(wù)定義
• 微服務(wù)的優(yōu)勢及架構(gòu)特點
• 微服務(wù)架構(gòu)下的數(shù)據(jù)設(shè)計
• 選擇一個合適的數(shù)據(jù)庫

-? ? ?什么是微服務(wù)? ? -

按照 Martin Fowler 的定義，微服務(wù)是一個軟件架構(gòu)模式，通過開發(fā)一系列的小型服務(wù)的方式來實現(xiàn)一個應(yīng)用。每一個這樣的小服務(wù)通常都是運行在自己的進(jìn)程里面，并且通過輕量級的 HTTP API 方式進(jìn)行通訊。這些服務(wù)通常會以業(yè)務(wù)模塊為界限，能夠被單獨開發(fā)部署，往往都會用自動化的部署工具來進(jìn)行產(chǎn)品的發(fā)布。通過使用微服務(wù)方法，大公司可以更快推出新產(chǎn)品和服務(wù)，使得開發(fā)團(tuán)隊與業(yè)務(wù)目標(biāo)保持一致。

-? ? ?微服務(wù)的優(yōu)勢? ? -

微服務(wù)方法體現(xiàn)出許多優(yōu)勢，包括更快的上線時間、靈活性、彈性、一致性以及相對更低的成本。

更快的上線時間

實施微服務(wù)架構(gòu)可以使組織更快地將其應(yīng)用程序推向市場。對整體應(yīng)用程序的更改（即使很?。┬枰匦虏渴鹫麄€應(yīng)用程序堆棧，從而引入風(fēng)險和復(fù)雜性。相反，服務(wù)的更新可以立即提交、測試和部署，對個別服務(wù)的更改不會影響系統(tǒng)的其他部分。

更好的靈活性和可擴(kuò)展性

微服務(wù)方法在擴(kuò)展應(yīng)用程序時也提供了靈活性。單片應(yīng)用程序要求整個系統(tǒng)（及其所有功能）同時擴(kuò)展。使用微服務(wù)，只需要縮放需要額外性能的組件或功能?？梢酝ㄟ^部署更多微服務(wù)實例來擴(kuò)展服務(wù)范圍，從而實現(xiàn)更有效的容量規(guī)劃并降低軟件許可成本，從而降低總體擁有成本。

彈性

使用單體應(yīng)用程序時，組件的故障可能會危及整個應(yīng)用程序。在微服務(wù)中，每項服務(wù)都是隔離的，以防止級聯(lián)失敗導(dǎo)致整個系統(tǒng)崩潰。如果單個微服務(wù)的所有實例均失敗，則整體服務(wù)可能會降級，但其他組件仍可提供有價值的服務(wù)。

更容易的規(guī)?；?/span>

微服務(wù)使技術(shù)團(tuán)隊能夠與組織需求保持一致，并且可以調(diào)整團(tuán)隊的大小以匹配所需的任務(wù)。通常，微服務(wù)團(tuán)隊規(guī)模較小但是跨部門（如一般涵蓋 Ops、Dev、QA），并專注于整個應(yīng)用程序的單個組件。通過提供對個人服務(wù)的所有權(quán)，而不是功能區(qū)域，微服務(wù)還可以打破團(tuán)隊之間的孤島，并改善協(xié)作。這種方法對于分布式和遠(yuǎn)程團(tuán)隊尤其強(qiáng)大。（例如，不同地點的團(tuán)隊可以獨立發(fā)布和部署功能。）

-? ? ?微服務(wù)的技術(shù)特點? ? -

讓我們來通過一個例子來了解微服務(wù)架構(gòu)的技術(shù)特點。

聯(lián)邦銀行的架構(gòu)師 Jonnathan 非常不喜歡他的產(chǎn)品經(jīng)理 Mandy，因為他覺得 Mandy 永遠(yuǎn)有無窮無盡的想法要實現(xiàn)，搞得他成天就在不斷地修改代碼。但是 Mandy 是老板的紅人，而且用戶對產(chǎn)品的反響也不錯，所以很多時候他只能默默的服從。

這一天 Mandy 又成功的說服了老板要在他們的客戶體驗提升項目中增加輿情分析和 AI 客戶服務(wù)模塊，希望通過對社交媒體上有關(guān)聯(lián)邦銀行的所有評論進(jìn)行實時的監(jiān)控和分析來及時發(fā)現(xiàn)聯(lián)邦銀行的產(chǎn)品反饋或者用戶體驗問題。Jonnathan 已經(jīng)預(yù)感到了這樣前所未有的應(yīng)用場景，會有太多的未知和太多的改變，于是這次決定嘗試使用 Microservices 來構(gòu)建這個應(yīng)用。

這個是 Jonnathan 設(shè)計的架構(gòu)，系統(tǒng)要求對客戶的社交賬號如 Facebook、Twitter、Google+ 及 Snapchat 公開的信息及評論進(jìn)行收集，并在某些合適的時候使用 AI 技術(shù)直接和用戶在通過社交工具進(jìn)行互動。

在上圖這個架構(gòu)里面，Jonnathan 把 4 個不同社交媒體的數(shù)據(jù)采集和交互用 4 個獨立的模塊進(jìn)行實現(xiàn)，并用一個 Feed Merge 服務(wù)，一個 Aggregate Service 把 4 個類似功能的微服務(wù)模塊的數(shù)據(jù)和功能進(jìn)行整合，提供給分析平臺使用。這里面每一個服務(wù)按照微服務(wù)的架構(gòu)，每一個都是單獨部署，在一個獨立的容器內(nèi)執(zhí)行，并使用自己的一個數(shù)據(jù)庫。

果不其然, 系統(tǒng)上線一段時間，Mandy 說 Google+ 上面幾乎沒有什么活動，不值得繼續(xù)維護(hù)這樣的一套系統(tǒng)。Jonnathan 這次毫無抱怨，直接把負(fù)責(zé) Google+ 的容器停了，沒有需要任何代碼改動，甚至完全沒有需要對整個系統(tǒng)進(jìn)行停機(jī)。

剛下線 Google+，Mandy 又來提需求說最近合并了另一家銀行，客戶很多使用 Whatsapp。二話不說，Jonnathan 直接上了一個新的模塊來處理 Whatsapp:?

又過了一段時間，這一次是 Jonnathan 自己要對系統(tǒng)做調(diào)整了，原來 Snapchat 最近大火，他部署的系統(tǒng)頻受壓力，性能下降。為了解決這個問題，Jonnathan 果斷增加了額外 2 臺容器來同時支撐 Snapchat 信息的采集和處理。?

感謝微服務(wù)架構(gòu)，Jonnathan 在一系列的產(chǎn)品需求變化以及系統(tǒng)擴(kuò)容需求下，可以從容應(yīng)付。要實現(xiàn)微服務(wù)架構(gòu)，需要你銘記以下幾個微服務(wù)架構(gòu)的應(yīng)用設(shè)計原則：

-? ? ?Decouple 解耦? ? -

在微服務(wù)架構(gòu)中，應(yīng)用程序被分解為小型的獨立服務(wù)。服務(wù)通常專注于特定的離散目標(biāo)或功能，并沿著業(yè)務(wù)邊界解耦。按業(yè)務(wù)界限分離服務(wù)可讓團(tuán)隊專注于正確的目標(biāo)，并確保服務(wù)之間的自主性。每項服務(wù)都是獨立開發(fā)，測試和部署的，服務(wù)通常是作為獨立的進(jìn)程或軟件容器分開的，通過網(wǎng)絡(luò)和商定的 API 進(jìn)行通信，盡管在某些情況下，網(wǎng)絡(luò)可能在本地。通常部署相同微服務(wù)的多個實例，從而提供冗余和可擴(kuò)展性。

-? ? ?Dump Pipes 輕量級 API? ? -

微服務(wù)之間的通信要使用輕量級 API，如 HTTP RESTful API。這樣可以使得服務(wù)對 API 通信方案的依賴減到最小。復(fù)雜的通信處理要在服務(wù)端進(jìn)行，而不是像 ESB 或者 Data Pipeline 處理總線那樣在數(shù)據(jù)傳輸過程中引入非常多的邏輯，導(dǎo)致微服務(wù)模塊緊緊的綁定在這個數(shù)據(jù)管道上。

DevOps 持續(xù)集成

微服務(wù)架構(gòu)帶來的一個非常顯著的負(fù)面性就是眾多實例的測試發(fā)布及管理。傳統(tǒng)應(yīng)用雖然開發(fā)復(fù)雜，但是部署和運維相對比較集中，一臺數(shù)據(jù)庫，2-4 個應(yīng)用服務(wù)器就差不多了。但是微服務(wù)架構(gòu)下單獨服務(wù)的數(shù)量輕則 10-20，多則上百個，所以微服務(wù)架構(gòu)一般需要配套的 CI/CD 方法來支撐。

Decentralized 去中心數(shù)據(jù)治理

數(shù)據(jù)的管理在微服務(wù)架構(gòu)下也是和傳統(tǒng)單體有很大的不同考量。大部分時候我們希望數(shù)據(jù)就和服務(wù)一樣，要有充分的獨立性，可以和某個服務(wù)一起部署，一起擴(kuò)展，或者一起重構(gòu)。這通常意味著我們可能要在一個微服務(wù)架構(gòu)應(yīng)用內(nèi)使用多個數(shù)據(jù)庫實例。但是同樣需要考慮到數(shù)據(jù)分布在多實例之間以后，往往還需要一些冗余，以及如何保持這些數(shù)據(jù)在這些系統(tǒng)中的一致性等問題。下面一章，我們就著重來討論微服務(wù)架構(gòu)下的數(shù)據(jù)設(shè)計的一些考量因素。

微服務(wù)的數(shù)據(jù)設(shè)計考量

從來沒有一個 one-size-fits-all 的架構(gòu)，所以在微服務(wù)架構(gòu)下面，我們需要了解的，一樣是幾個關(guān)鍵的架構(gòu)考量點。然后針對自己的實際應(yīng)用，選擇哪些考量點是更加重要。這篇文章的目的，主要就是跟大家來討論從哪幾個角度著手來設(shè)計一個符合微服務(wù)架構(gòu)原則的數(shù)據(jù)架構(gòu)。比如說，我們可以從一系列的問題來開始這個討論：

• 這么多微服務(wù)之間，我是否可以用一個數(shù)據(jù)庫，還是多個數(shù)據(jù)庫來支持多個微服務(wù)？
• 如果是多個數(shù)據(jù)庫，我是否為每一個微服務(wù)挑選一個最合適的數(shù)據(jù)庫，還是選擇同一種類型的數(shù)據(jù)庫？
• 我如何在微服務(wù)架構(gòu)下擴(kuò)展我的數(shù)據(jù)庫？
• 當(dāng)一個我依賴的服務(wù)需要修改數(shù)據(jù)庫 Schema 的時候，是否會影響到我？
• 當(dāng)微服務(wù)應(yīng)用不斷衍變的時候，我的數(shù)據(jù)庫是否可以快速的響應(yīng)應(yīng)用需求變化？

這些就是我們在微服務(wù)數(shù)據(jù)架構(gòu)時候要關(guān)注的地方。

-? ? ?一庫一服還是一庫多服? ? -

無論是單體應(yīng)用，還是微服務(wù)應(yīng)用，有一點是肯定的：應(yīng)用的各個模塊之間都需要進(jìn)行較為頻繁的通信，通過一起協(xié)同合作，來實現(xiàn)應(yīng)用的整體價值。在單體應(yīng)用中，這種通信是通過方法調(diào)用來完成的。在微服務(wù)中，則通過 API 調(diào)用來完成。這些模塊或者服務(wù)間調(diào)用，大部分時候是為了共享數(shù)據(jù)。共享數(shù)據(jù)最賤的方式當(dāng)然就是采用一種共享數(shù)據(jù)庫的模式，也就是單體應(yīng)用常用的方式 - 應(yīng)用可以有多個系統(tǒng)模塊，但一般都是只有一個數(shù)據(jù)庫。如下圖左邊，3 個微服務(wù)模塊，后面共享一個數(shù)據(jù)庫，簡稱一庫多服務(wù)：

這種架構(gòu)模式通常會被認(rèn)為是微服務(wù)架構(gòu)下的反范式，它的問題在于：

• 單點故障：一個數(shù)據(jù)庫倒下，整批服務(wù)全部停止。何來的服務(wù)獨立性？
• 數(shù)據(jù)在同一個地方，會給貪圖方便的開發(fā)或者 DBA 工程師編寫很多數(shù)據(jù)間高度依賴的程序或者工具；
• 無法針對某一個服務(wù)進(jìn)行精準(zhǔn)優(yōu)化或擴(kuò)展，如上文所講的 Snapchat 的例子。

所以一般推薦的做法，是為每一個微服務(wù)準(zhǔn)備一個單獨的數(shù)據(jù)庫，也即一庫一服 (database per service) ?模式。如上圖右側(cè)所示。這種模式更加適合微服務(wù)架構(gòu) - 它滿足每一個服務(wù)是獨立開發(fā)、獨立部署、獨立擴(kuò)展的特性。當(dāng)需要對一個服務(wù)進(jìn)行升級或者數(shù)據(jù)架構(gòu)改動的時候，無須影響到其他的服務(wù)。需要對某個服務(wù)進(jìn)行擴(kuò)展的時候，也可以手術(shù)式的對某一個服務(wù)進(jìn)行局部擴(kuò)容。另外，如果某些服務(wù)對數(shù)據(jù)庫有特殊的需求，這種模式也為下文所講的混合持久化 (Polyglot Persistence) 提供了可能性。

-? ? ?混合持久化 vs 多模數(shù)據(jù)庫? ? -

混合持久化在大型互聯(lián)網(wǎng)公司是一個比較風(fēng)行的模式。它秉承的原則就是為特別的任務(wù)提供最好的工具。比如說，如果我希望提供一個高并發(fā)低延遲的共享用戶會話方案 (shared session storage)， Redis 可能是一個非常理想的選擇。如果我是在實現(xiàn)一個產(chǎn)品目錄，涉及到大量不定結(jié)構(gòu)的商品數(shù)據(jù)及屬性的建模管理，我可能會采用模式靈活，動態(tài) schema 的 MongoDB 來作為我的數(shù)據(jù)庫解決方案。如果我希望支持非常強(qiáng)大的全文搜索，ElasticSearch 則是行業(yè)中的佼佼者。微服務(wù)的功能分塊獨立部署為這種架構(gòu)模式提供了非常好的基礎(chǔ)，如下圖左側(cè)所示就是個典型的混合持久化的案例：

• 混合持久化?- Polyglot Persistence

• 多模數(shù)據(jù)庫 - Multi-model Database

當(dāng)然，有句話說的是架構(gòu)師的工作就是每天做不斷的取舍 (trade off)，因為選擇往往是讓人很糾結(jié)?；旌铣志没膬?yōu)勢很明顯，可以讓每個單獨的服務(wù)使用到最佳的工具和技術(shù)。但是它的弊端也是不容忽視。部署、監(jiān)控、備份、升級等數(shù)據(jù)庫管理工作從來都是一件困難但是重要的任務(wù)。

引入多個不同的數(shù)據(jù)庫，也意味著對系統(tǒng)管理維護(hù)的復(fù)雜度和成本提高了很多。這種情況下可能需要比較有資源的公司或者團(tuán)隊才可以使用。這也解釋了這個模式在大型互聯(lián)網(wǎng)公司得到較多的采用與推廣。針對于其他小型規(guī)模的用戶，或者是缺乏足夠掌握各種新型技術(shù)人才的公司來說，另一種更為可行的模式可能是多模數(shù)據(jù)庫 (Multi-model)。如上圖右側(cè)所示。

多模數(shù)據(jù)庫的特征是：

• 依然是一庫一服務(wù)（為一個服務(wù)部署一個單獨的數(shù)據(jù)庫）；
• 但是使用的是同一種類型，支持多種場景的數(shù)據(jù)庫，如 NoSQL 中間為功能最全面的 MongoDB；
• 雖然是多實例，但是只需維護(hù)一種類型的數(shù)據(jù)庫，管理上和人員配備上都較為簡單。

如果你在開發(fā)的應(yīng)用是一款企業(yè)級產(chǎn)品，會交付到客戶環(huán)境部署安裝，則運維管理的簡單性將在技術(shù)選型中占據(jù)非常重要的一個比重，無疑這種情況下多模數(shù)據(jù)庫更加適用。

-? ? ?微服務(wù)擴(kuò)展你的數(shù)據(jù)? ? -

微服務(wù)架構(gòu)的一大裨益是其靈活的擴(kuò)展性。以上面的 Snapchat 為例，如果需要采集或處理的數(shù)據(jù)量快速增長，在我們增加應(yīng)用服務(wù)實例的同時，支撐數(shù)據(jù)存儲的模塊也要相應(yīng)擴(kuò)充。AFK Partners 在他們的 Scale Cube 一文里對性能擴(kuò)展提出了這樣的觀點：要設(shè)計一個真正意義上的可擴(kuò)展系統(tǒng)，我們必須考慮 3 個維度，如下所示：

·?X-軸, 系統(tǒng)復(fù)制（橫向擴(kuò)展）

·?Y-軸, 非重疊功能的拆分（微服務(wù)）

·?Z-軸, 數(shù)據(jù)的分區(qū) (Sharding)

一個好的數(shù)據(jù)架構(gòu)，在微服務(wù)體系內(nèi)，應(yīng)該具有同樣的可擴(kuò)展、易擴(kuò)展性質(zhì)，從而不給微服務(wù)架構(gòu)拖后腿。關(guān)于數(shù)據(jù)分區(qū)擴(kuò)展有兩種做法：

• 應(yīng)用數(shù)據(jù)分區(qū)
• 數(shù)據(jù)庫分區(qū)

應(yīng)用數(shù)據(jù)分區(qū)，顧名思義，就是在應(yīng)用端對數(shù)據(jù)的存儲進(jìn)行分區(qū)管理。比如說，一個社交應(yīng)用可以按國家或地區(qū)為界把用戶的數(shù)據(jù)分發(fā)到不同數(shù)據(jù)庫實例里面。這樣的話每個數(shù)據(jù)庫實例只需要存儲一部分?jǐn)?shù)據(jù)，從而實現(xiàn)海量的數(shù)據(jù)管理能力。數(shù)據(jù)庫分區(qū)，就是由數(shù)據(jù)庫的路由節(jié)點來完成數(shù)據(jù)分區(qū)的任務(wù)。數(shù)據(jù)庫分區(qū)的優(yōu)勢是顯然的 - 對應(yīng)用透明、擴(kuò)展快速、無須下線等。如果你的應(yīng)用有潛在擴(kuò)充的需求，選擇一個能夠自動擴(kuò)展的分布式數(shù)據(jù)庫是一個比較明智的選擇。

-? ? ?動態(tài)模式支持及快速開發(fā)能力? ? -

這是一個很多架構(gòu)師可能會忽略，但是非常重要的關(guān)注點。我們在迭代式開發(fā) DevOps 微服務(wù)上的很多努力，都是為了快速開發(fā)，快速上線，以及快速響應(yīng)變化的需求。從數(shù)據(jù)架構(gòu)師的角度來看，如何不成為在這個快速開發(fā)方法模式中的一個瓶頸，有一個很重要的環(huán)節(jié)就是是否有一個能夠及時響應(yīng)變化的數(shù)據(jù)模型。傳統(tǒng)的數(shù)據(jù)庫都是強(qiáng)模式，需要對 schema 進(jìn)行清晰定義, 在需求修改導(dǎo)致模型修改的時候需要對數(shù)據(jù)庫進(jìn)行模式升級，是一個需要下線、耗時并且是高成本的運維操作。

在新一代的 NoSQL 數(shù)據(jù)庫產(chǎn)生之前，我們并不需要考慮這個問題，但是以 MongoDB、Cassandra 等為代表的 NoSQL 代表的是靈活建模，動態(tài)支持模式變化的特征使得它們成為敏捷開發(fā)和微服務(wù)體系內(nèi)一個有力的競爭者，在選型的時候也是一個重要的考量因素之一。我們說一庫一服的架構(gòu)使得對一個服務(wù)的數(shù)據(jù)庫模式修改不會影響到其他服務(wù)。但是如果使用一個動態(tài)模式（有時候有人會說無模式）的數(shù)據(jù)庫，則在該服務(wù)本身模式修改時候也可以最小化其最小化的維運成本。

-? ? ?一個適合微服務(wù)架構(gòu)的數(shù)據(jù)庫? ? -

紅杉資本的合伙人 Matt Miller 是公認(rèn)的微服務(wù)技術(shù)領(lǐng)域?qū)＜?。他的廣被傳播的“微服務(wù)生態(tài)圖”詳盡的列出了微服務(wù)架構(gòu)的相關(guān)技術(shù)棧。在這里他推薦了 MongoDB 作為主要的數(shù)據(jù)管理方案。

MongoDB 是一個分布式文檔型數(shù)據(jù)庫，它有以下一些特性使它非常適合于微服務(wù)架構(gòu)：

• 多模數(shù)據(jù)庫 (Multi-model)
• 原生 JSON 數(shù)據(jù)結(jié)構(gòu) - API
• 動態(tài)模式、無模式 (Dynamic schema / Schemaless)
• 數(shù)據(jù)變化流 (Change Stream)
• 橫向擴(kuò)展能力 (Sharding)

-? ? ?多模數(shù)據(jù)庫? ? -

MongoDB 從 3.4 版本起在多模數(shù)據(jù)庫場景上提供了不少功能模塊，比如說，使用聚合框架 (Aggregation Framework) 現(xiàn)在開發(fā)者可以使用

• $graphLookup 來實現(xiàn)類似于圖數(shù)據(jù)庫的查詢
• $facet 來實現(xiàn)分面搜索。
• 內(nèi)存引擎功能，用于支持類似于 Redis 的高速緩存
• 全文檢索，用于實現(xiàn)搜索類型場景

-? ? ?JSON 數(shù)據(jù)結(jié)構(gòu)? ? -

由于 MongoDB 原生就是 JSON 數(shù)據(jù)模型，正好是微服務(wù)架構(gòu)中用于模塊間通信的 HTTP RESTful API 調(diào)用的主要數(shù)模型。事實上，你可以使用一些開源中間件，快速的來構(gòu)建起微服務(wù)之間的 API 服務(wù)。

動態(tài)模式

這一點一直是 MongoDB 獲得開發(fā)者青睞的主要原因之一。MongoDB 無須顯式的定義數(shù)據(jù)模式即可讓你開始往數(shù)據(jù)庫寫入。當(dāng)數(shù)據(jù)模型有變化時候，比如說在迭代式開發(fā)中非常常見的就是增加一些字段，MongoDB 數(shù)據(jù)庫不需要對其進(jìn)行修改 schema 操作，而是可以直接在同一個集合（表）里直接寫入新版本的文檔。這個對于需要實現(xiàn)快速迭代，快速交付的微服務(wù)應(yīng)用開發(fā)是一個非常重要的特性。

數(shù)據(jù)更改流

微服務(wù)架構(gòu)中由于其分布特性，傳統(tǒng)的強(qiáng)事務(wù)機(jī)制不再適用。數(shù)據(jù)的一致性一般需要通過一些基于 Event Sourcing 或者事件驅(qū)動模型的解決方案。MongoDB 3.6 版本推出的數(shù)據(jù)更改流，可以用來實現(xiàn)一個類似于 Kafak 一樣的 Message Queue，為各個微服務(wù)間的數(shù)據(jù)協(xié)調(diào)提供一個簡單易用的線程方案。

-? ? ?橫向擴(kuò)展能力? ? -

MongoDB 一向以其強(qiáng)大的橫向擴(kuò)展能力著稱。不少 MongoDB 用戶遷移的主要原因就是使用 MongoDB 的 sharding 技術(shù)可以突破關(guān)系型數(shù)據(jù)庫在數(shù)據(jù)量和性能上的瓶頸。MongoDB 的 sharding 有幾個特征使得其非常適合微服務(wù)架構(gòu)考慮使用：

• 彈性擴(kuò)展：可以擴(kuò)容也可以縮容；
• 無縫擴(kuò)展：無須停機(jī)，就可在線擴(kuò)容；
• 自動均衡：無須應(yīng)用參與即可實現(xiàn)數(shù)據(jù)的自動均衡，完全透明。

一個基于 MongoDB 的微服務(wù)參考架構(gòu)圖

作者：唐建法

來源：Mongoing中文社區(qū)