Feed流系統設計-總綱

時間 2020-04-09

標籤 feed 系統設計總綱简体版

原文原文鏈接

簡介

差很少十年前，隨着功能機的淘汰和智能機的普及，互聯網開始進入移動互聯網時代，最具表明性的產品就是微博、微信，以及後來的今日頭條、快手等。這些移動化聯網時代的新產品在過去幾年間藉着智能手機的風高速成長。算法

這些產品都是Feed流類型產品，因爲Feed流通常是按照時間「從上往下流動」，很是適合在移動設備端瀏覽，最終這一類應用就脫穎而出，迅速搶佔了上一代產品的市場空間。數據庫

Feed流是Feed + 流，Feed的本意是飼料，Feed流的本意就是有人一直在往一個地方投遞新鮮的飼料，若是須要飼料，只須要盯着投遞點就能夠了，這樣就能源源不斷獲取到新鮮的飼料。在信息學裏面，Feed實際上是一個信息單元，好比一條朋友圈狀態、一條微博、一條諮詢或一條短視頻等，因此Feed流就是不停更新的信息單元，只要關注某些發佈者就能獲取到源源不斷的新鮮信息，咱們的用戶也就能夠在移動設備上逐條去瀏覽這些信息單元。緩存

當前最流行的Feed流產品有微博、微信朋友圈、頭條的資訊推薦、快手抖音的視頻推薦等，還有一些變種，好比私信、通知等，這些系統都是Feed流系統，接下來咱們會介紹如何設計一個Feed流系統架構。微信

Feed流系統特色

Feed流本質上是一個數據流，是將「N個發佈者的信息單元」經過「關注關係」傳送給「M個接收者」。session

Feed流系統是一個數據流系統，因此咱們核心要看數據。從數據層面看，數據分爲三類，分別是：架構

發佈者的數據：發佈者產生數據，而後數據須要按照發布者組織，須要根據發佈者查到全部數據，好比微博的我的頁面、朋友圈的我的相冊等。
關注關係：系統中個體間的關係，微博中是關注，是單向流，朋友圈是好友，是雙向流。無論是單向仍是雙向，當發佈者發佈一條信息時，該條信息的流動永遠是單向的。
接收者的數據：從不一樣發佈者那裏獲取到的數據，而後經過某種順序（通常爲時間）組織在一塊兒，好比微博的首頁、朋友圈首頁等。這些數據具備時間熱度屬性，越新的數據越有價值，越新的數據就要排在最前面。

針對這三類數據，咱們能夠有以下定義：框架

存儲庫：存儲發佈者的數據，永久保存。
關注表：用戶關係表，永久保存。
同步庫：存儲接收者的時間熱度數據，只須要保留最近一段時間的數據便可。

設計Feed流系統時最核心的是肯定清楚產品層面的定義，須要考慮的因素包括：運維

產品用戶規模：用戶規模在十萬、千萬、十億級時，設計難度和側重點會不一樣。
關注關係（單向、雙寫）：若是是雙向，那麼就不會有大V，不然會有大V存在。
上述是選擇數據存儲系統最核心的幾個考慮點，除此以外，還有一些須要考慮的：
如何實現Meta和Feed內容搜索？分佈式
- 雖然Feed流系統自己能夠不須要搜索，可是一個Feed流產品必需要有搜索，不然信息發現難度會加大，用戶留存率會大幅降低。
Feed流的順序是時間仍是其餘分數，好比我的的喜愛程度？優化
- 雙向關係時因爲關係很緊密，必定是按時間排序，就算一個關係很緊密的人發了一條空消息或者低價值消息，那咱們也會須要關注瞭解的。
- 單向關係時，那麼可能就會存在大V，大V的粉絲數量理論極限就是整個系統的用戶數，有一些產品會讓全部用戶都默認關注產品負責人，這種產品中，該負責人就是最大的大V，粉絲數就是用戶規模。
  接下來，咱們看看整個Feed流系統如何設計。

Feed流系統設計

上一節，咱們提早思考了Feed流系統的幾個關鍵點，接下來，在這一節，咱們自頂向下來設計一個Feed流系統。

1. 產品定義

第一步，咱們首先須要定義產品，咱們要作的產品是哪種類型，常見的類型有：

微博類
朋友圈類
抖音類
私信類

接着，再詳細看一下這幾類產品的異同：

類型	關注關係	是否有大V	時效性	排序
微博類	單向	有	秒~分	時間
抖音類	單向/無	有	秒~分	推薦
朋友圈類	雙向	無	秒	時間
私信類	雙向	無	秒	時間

上述對比中，只對比各種產品最核心、或者最根本特色，其餘次要的不考慮。好比微博中互相關注後就是雙向關注了，可是這個不是微博的立命之本，只是補充，沒法撼動根本。

從上面表格能夠看出來，主要分爲兩種區分：

關注關係是單向仍是雙向：
- 若是是單向，那麼可能就會存在大V效應，同時時效性能夠低一些，好比到分鐘級別；
- 若是是雙向，那就是好友，好友的數量有限，那麼就不會有大V，由於每一個人的精力有限，他不可能主動加幾千萬的好友，這時候由於關係更精密，時效性要求會更高，須要都秒級別。
排序是時間仍是推薦：
- 用戶對feed流最容易接受的就是時間，目前大部分都是時間。
- 可是有一些場景，是從全網數據裏面根據用戶的喜愛給用戶推薦和用戶喜愛度最匹配的內容，這個時候就須要用推薦了，這種狀況通常也會省略掉關注了，相對於關注了全網全部用戶，好比抖音、頭條等。
  肯定了產品類型後，還須要繼續肯定的是系統設計目標：須要支持的最大用戶數是多少？十萬、百萬、千萬仍是億？

用戶數不多的時候，就比較簡單，這裏咱們主要考慮億級用戶的狀況，由於若是系統能支持億級，那麼其餘量級也能支持。爲了支持億級規模的用戶，主要子系統選型時須要考慮水平擴展能力以及一些子系統的可用性和可靠性了，由於系統大了後，任何一個子系統的不穩定都很容易波及整個系統。

2. 存儲

咱們先來看看最重要的存儲，無論是哪一種同步模式，在存儲上都是同樣的，咱們定義用戶消息的存儲爲存儲庫。存儲庫主要知足三個需求：

可靠存儲用戶發送的消息，不能丟失。不然就找不到本身曾經發布到朋友圈狀態了。
讀取某我的發佈過的全部消息，好比我的主頁等。
數據永久保存。

因此，存儲庫最重要的特徵就是兩點：

數據可靠、不丟失。
因爲數據要永久保存，數據會一直增加，因此要易於水平擴展。

綜上，能夠選爲存儲庫的系統大概有兩類：

特色	分佈式NoSQL	關係型數據庫（分庫分表）
可靠性	極高	高
水平擴展能力	線性	須要改造
水平擴展速度	毫秒	無
常見系統	Tablestore、Bigtable	MySQL、PostgreSQL

對於可靠性，分佈式NoSQL的可靠性要高於關係型數據庫，這個可能有違不少人的認知。主要是關係型數據庫發展很長時間了，且很成熟了，數據放在上面你們放心，而分佈式NoSQL數據庫發展晚，使用的並很少，不太信任。可是，分佈式NoSQL須要存儲的數據量更多，對數據可靠性的要求也加嚴格，因此通常都是存儲三份，可靠性會更高。目前在一些雲廠商中的關係型數據庫由於採用了和分佈式NoSQL相似的方式，因此可靠性也獲得了大幅提升。
水平擴展能力：對於分佈式NoSQL數據庫，數據自然是分佈在多臺機器上，當一臺機器上的數據量增大後，能夠經過自動分裂兩部分，而後將其中一半的數據遷移到另外一臺機器上去，這樣就作到了線性擴展。而關係型數據庫須要在擴容時再次分庫分表。

因此，結論是：

若是是自建系統，且不具有分佈式NoSQL數據庫運維能力，且數據規模不大，那麼可使用MySQL，這樣能夠撐一段時間。
若是是基於雲服務，那麼就用分佈式NoSQL，好比Tablestore或Bigtable。
若是數據規模很大，那麼也要用分佈式NoSQL，不然就是走上一條不歸路。

若是使用Tablestore，那麼存儲庫表設計結構以下：

主鍵列	第一列主鍵	第二列主鍵	屬性列	屬性列
列名	user_id	message_id	content	other
解釋	消息發送者用戶ID	消息順序ID，可使用timestamp。	內容	其餘內容

到此，咱們肯定了存儲庫的選型，那麼系統架構的輪廓有了：

3. 同步

系統規模和產品類型，以及存儲系統肯定後，咱們能夠肯定同步方式，常見的方式有三種：

推模式（也叫寫擴散）：和名字同樣，就是一種推的方式，發送者發送了一個消息後，當即將這個消息推送給接收者，可是接收者此時不必定在線，那麼就須要有一個地方存儲這個數據，這個存儲的地方咱們稱爲：同步庫。推模式也叫寫擴散的緣由是，一個消息須要發送個多個粉絲，那麼這條消息就會複製多份，寫放大，因此也叫寫擴散。這種模式下，對同步庫的要求就是寫入能力極強和穩定。讀取的時候由於消息已經發到接收者的收件箱了，只須要讀一次本身的收件箱便可，讀請求的量極小，因此對讀的QPS需求不大。概括下，推模式中對同步庫的要求只有一個：寫入能力強。
拉模式（也叫讀擴散）：這種是一種拉的方式，發送者發送了一條消息後，這條消息不會當即推送給粉絲，而是寫入本身的發件箱，當粉絲上線後再去本身關注者的發件箱裏面去讀取，一條消息的寫入只有一次，可是讀取最多會和粉絲數同樣，讀會放大，因此也叫讀擴散。拉模式的讀寫比例恰好和寫擴散相反，那麼對系統的要求是：讀取能力強。另外這裏還有一個誤區，不少人在最開始設計feed流系統時，首先想到的是拉模式，由於這種和用戶的使用體感是同樣的，可是在系統設計上這種方式有很多痛點，最大的是每一個粉絲須要記錄本身上次讀到了關注者的哪條消息，若是有1000個關注者，那麼這我的須要記錄1000個位置信息，這個量和關注量成正比的，遠比用戶數要大的多，這裏要特別注意，雖然在產品前期數據量少的時候這種方式能夠應付，可是量大了後就會事倍功半，得不償失，切記切記。
推拉結合模式：推模式在單向關係中，由於存在大V，那麼一條消息可能會擴散幾百萬次，可是這些用戶中可能有一半可能是殭屍，永遠不會上線，那麼就存在資源浪費。而拉模式下，在系統架構上會很複雜，同時須要記錄的位置信息是天量，很差解決，尤爲是用戶量多了後會成爲第一個故障點。基於此，因此有了推拉結合模式，大部分用戶的消息都是寫擴散，只有大V是讀擴散，這樣既控制了資源浪費，又減小了系統設計複雜度。可是總體設計複雜度仍是要比推模式複雜。

用圖表對比：

類型	推模式	拉模式	推拉結合模式
寫放大	高	無	中
讀放大	無	高	中
用戶讀取延時	毫秒	秒	秒
讀寫比例	1:99	99:1	~50:50
系統要求	寫能力強	讀能力強	讀寫都適中
常見系統	Tablestore、Bigtable等LSM架構的分佈式NoSQL	Redis、memcache等緩存系統或搜索系統(推薦排序場景)	二者結合
架構複雜度	簡單	複雜	更復雜

介紹完同步模式中全部場景和模式後，咱們概括下：

若是產品中是雙向關係，那麼就採用推模式。
若是產品中是單向關係，且用戶數少於1000萬，那麼也採用推模式，足夠了。
若是產品是單向關係，單用戶數大於1000萬，那麼採用推拉結合模式，這時候能夠從推模式演進過來，不須要額外從新推翻重作。
永遠不要只用拉模式。
若是是一個初創企業，先用推模式，快速把系統設計出來，而後讓產品去驗證、迭代，等客戶數大幅上漲到1000萬後，再考慮升級爲推拉集合模式。
若是是按推薦排序，那麼是另外的考慮了，架構會徹底不同，這個後面專門文章介紹。

若是選擇了Tablestore，那麼同步庫表設計結構以下：

主鍵列	第一列主鍵	第二列主鍵	屬性列	屬性列	屬性列
列名	user_id	sequence_id	sender_id	message_id	other
解釋	消息接收者用戶ID	消息順序ID，可使用timestamp + send_user_id，也能夠直接使用Tablestore的自增列。	發送者的用戶ID	store_table中的message_id列的值，也就是消息ID。經過sender_id和message_id能夠到store_table中查詢到消息內容	其餘內容，同步庫中不須要包括消息內容。

肯定了同步庫的架構以下：

4. 元數據

前面介紹了同步和存儲後，整個Feed流系統的基礎功能完成了，可是對於一個完整Feed流產品而言，還缺元數據部分，接下來，咱們看元數據如何處理：

Feed流系統中的元數據主要包括：

用戶詳情和列表。
關注或好友關係。
推送session池。

咱們接下來逐一來看。

4.1 用戶詳情和列表

主要是用戶的詳情，包括用戶的各類自定義屬性和系統附加的屬性，這部分的要求只須要根據用戶ID查詢到就能夠了。

能夠採用的分佈式NoSQL系統或者關係型數據庫均可以。

若是使用NoSQL數據庫Tablestore，那麼用戶詳情表設計結構以下：

主鍵順序	第一列主鍵	屬性列-1	屬性列-2	......
字段名	user_id	nick_name	gender	other
備註	主鍵列，用於惟一肯定一個用戶	用戶暱稱，用戶自定義屬性	用戶性別，用戶自定義屬性	其餘屬性，包括用戶自定義屬性列和系統附加屬性列。Tablestore是FreeSchema類型的，能夠隨時在任何一行增長新列而不影響原有數據。

4.2 關注或好友關係

這部分是存儲關係，查詢的時候須要支持查詢關注列表或者粉絲列表，或者直接好友列表，這裏就須要根據多個屬性列查詢須要索引能力，這裏，存儲系統也能夠採用兩類，關係型、分佈式NoSQL數據庫。

若是已經有了關係型數據庫了，且數據量較少，則選擇關係型數據庫，好比MySQL等。
若是數據量比較大，這個時候就有兩種選擇：
- 1. 須要分佈式事務，能夠採用支持分佈式事務的系統，好比分佈式關係型數據庫。
- 1. 使用具備索引的系統，好比雲上的Tablestore，更簡單，吞吐更高，擴容能力也一併解決了。

若是使用Tablestore，那麼關注關係表設計結構以下：

Table：user_relation_table

主鍵順序	第一列主鍵	第一列主鍵	屬性列	屬性列
Table字段名	user_id	follow_user_id	timestamp	other
備註	用戶ID	粉絲用戶ID	關注時間	其餘屬性列

多元索引的索引結構：

Table字段名	user_id	follow_user_id	timestamp
是否Index	是	是	是
是否enableSortAndAgg	是	是	是
是否store	是	是	是

查詢的時候：

若是須要查詢某我的的粉絲列表：使用TermQuery查詢固定user_id，且按照timestamp排序。
若是須要查詢某我的的關注列表：使用TermQuery查詢固定follow_user_id，且按照timestamp排序。
當前數據寫入Table後，須要5~10秒鐘延遲後會在多元索引中查詢到，將來會優化到2秒之內。

除了使用多元索引外，還可使用GlobalIndex。

4.3 推送session池

思考一個問題，發送者將消息發送後，接收者如何知道本身有新消息來了？客戶端週期性去刷新？若是是這樣子，那麼系統的讀請求壓力會隨着客戶端增加而增加，這時候就會有一個風險，好比平時的設備在線率是20%~30%，忽然某天平臺爆發了一個熱點消息，大量休眠設備登錄，這個時候就會出現「查詢風暴」，一會兒就把系統打垮了，全部的用戶都不能用了。

解決這個問題的一個思路是，在服務端維護一個推送session池，這個裏面記錄哪些用戶在線，而後當用戶A發送了一條消息給用戶B後，服務端在寫入存儲庫和同步庫後，再通知一下session池中的用戶B的session，告訴他：你有新消息了。而後session-B再去讀消息，而後有消息後將消息推送給客戶端。或者有消息後給客戶端推送一下有消息了，客戶端再去拉。

這個session池使用在同步中，可是本質仍是一個元數據，通常只須要存在於內存中便可，可是考慮到failover狀況，那就須要持久化，這部分數據因爲只須要指定單Key查詢，用分佈式NoSQL或關係型數據庫均可以，通常複用當前的系統便可。

若是使用Tablestore，那麼session表設計結構以下：

主鍵列順序	第一列主鍵	第二列主鍵	屬性列
列名	user_id	device_id	last_sequence_id
備註	接收者用戶ID	設備ID，同一個用戶可能會有多個設備，不一樣設備的讀取位置可能不一致，因此這裏須要一個設備ID。若是不須要支持多終端，則這一列能夠省略。	該接收者已經推送給客戶端的最新的順序ID

5. 評論
除了私信類型外，其餘的feed流類型中，都有評論功能，評論的屬性和存儲庫差很少，可是多了一層關係：被評論的消息，因此只要將評論按照被被評論消息分組組織便可，而後查詢時也是一個範圍查詢就行。這種查詢方式很簡單，用不到關係型數據庫中複雜的事務、join等功能，很適合用分佈式NoSQL數據庫來存儲。

因此，通常的選擇方式就是：

若是系統中已經有了分佈式NoSQL數據庫，好比Tablestore、Bigtable等，那麼直接用這些便可。
若是沒有上述系統，那麼若是有MySQL等關係型數據庫，那就選關係型數據庫便可。
若是選擇了Tablestore，那麼「評論表」設計結構以下：

主鍵列順序	第一列主鍵	第二列主鍵	屬性列	屬性列	屬性列
字段名	message_id	comment_id	comment_content	reply_to	other
備註	微博ID或朋友圈ID等消息的ID	這一條評論的ID	評論內容	回覆給哪一個用戶	其餘

若是須要搜索評論內容，那麼對這張表創建多元索引便可。

6. 贊
最近幾年，「贊」或「like」功能很流行，贊功能的實現和評論相似，只是比評論少了一個內容，因此選擇方式和評論同樣。

若是選擇了Tablestore，那麼「贊表」設計結構同評論表，這裏就再也不贅述了。

系統架構中加了元數據系統後的架構以下：

7. 搜索
到此，咱們已經介紹完了Feed流系統的主題架構，Feed流系統算是完成了。可是Feed流產品上還未結束，對於全部的feed流產品都須要有搜索能力，好比下面場景：

微博中的搜索用戶。
搜索微博內容。
微信中搜索好友等。

這些內容搜索只須要字符匹配到便可，不須要很是複雜的相關性算法，因此只須要有能支持分詞的檢索功能便可，因此通常有兩種作法：

使用搜索引擎，將存儲庫的內容和用戶信息表內容推送給搜索系統，搜索的時候直接訪問搜索系統。
使用具有全文檢索能力的數據庫，好比最新版的MySQL、MongoDB或者Tablestore。

因此，選擇的原則以下：

若是存儲庫使用了MySQL或者Tablestore，那麼直接選擇這兩個系統就能夠了。
若是整個系統都沒使用MySQL、Tablestore，且已經使用了搜索系統，那麼能夠直接複用搜索系統，其餘場景都不該該再額外加一個搜索系統進來，徒添複雜度。

若是使用Tablestore，那麼只須要在相應表上創建多元索引便可：

若是須要對用戶名支持搜索，那麼須要對user_table創建多元索引，其中的nick_name須要是Text類型，且單字分詞。
若是須要對Feed流內容支持搜索，那麼須要對存儲庫表：store_table創建多元索引，這樣就能直接對Feed流內容進行各類複雜查詢了，包括多條件篩選、全文檢索等。

系統架構中加了搜索功能後的架構以下：

8. 排序
目前的Feed流系統中的排序方式有兩種，一種是時間，一種是分數。

咱們經常使用的微博、朋友圈、私信這些都是時間線類型的，由於這些產品定義中，須要咱們主動關注某些人後纔會看到這些人發表的內容，這個時候，最重要的是實時性，而不是發佈質量，就算關注人發佈了一條垃圾信息，咱們也會被動看到。這種類型的產品適用於按照時間線排序。這一篇咱們介紹的架構都是基於時間類型的。

另一種是不須要關注任何人，咱們能看到的都是系統但願咱們看到的，系統在後臺會分析咱們的每一個人的愛好，而後給每一個人推送差別化的、各自喜歡的內容，這一種的架構和基於時間的徹底不同，咱們在後續的推薦類型中專門介紹。

9. 刪除Feed內容
在Feed流應用中有一個問題，就是若是用戶刪除了以前發表的內容，系統該如何處理？由於系統裏面有寫擴散，那麼刪除的時候是否是也要寫擴散一遍？這樣的話，刪除就不及時了，很難應對法律法規要求的快速刪除。

針對這個問題，咱們在以前設計的時候，同步表中只有消息ID，沒有消息內容，在用戶讀取的時候須要到存儲庫中去讀消息內容，那麼咱們能夠直接刪除存儲庫中的這一條消息，這樣用戶讀取的時候使用消息ID是讀不到數據的，也就至關於刪除的內容，並且刪除速度會很快。除了直接刪除外，另一種辦法是邏輯刪除，對於刪除的feed內容，只作標記，當查詢到帶有標記的數據時就認爲刪除了。

10. 更新Feed內容
更新和刪除Feed處理邏輯同樣，若是使用了支持多版本的存儲系統，好比Tablestore，那麼也能夠支持編輯版本，和如今的微博同樣。

11. 總結
上面介紹了不一樣子功能的特色和系統要求，能知足需求的系統主要有兩類，一類是阿里雲的Tablestore單系統，一類是開源組件組成的組合系統。

開源組件組成的組合系統：包括MySQL、Redis、HBase等，這些系統單個都不能解決Feed流系統中遇到的問題，須要組合在一塊兒，各司其職才能完成一個Feed流系統，適用於熱衷開源系統，人多且喜歡運維操做的團隊。
Tablestore單系統：只使用Tablestore單個系統就能解決上述的全部問題，這時候確定有人要問？你是否是在吹牛？這裏不是吹牛，Tablestore在三年前就已經開始重視Feed流類型業務，以前也發表過多篇文章介紹，功能上也在專門爲Feed流系統特別定製設計，因此到今天，只使用Tablestore一款產品，是能夠知足上述需求的。選擇Tablestore作Feed流系統的用戶具備如下一些特徵：
- 產品設計目標規模大，千萬級或億級。
- 不喜歡運維，喜歡專一於開發。
- 高效率團隊，但願儘快將產品實現落地。
- 但願一勞永逸，將來系統隨着用戶規模增加能夠自動擴容。
- 但願能按量付費，用戶少的時候費用低，等用戶增加起來後費用在跟隨用戶數增加。
  若是具備上述四個特徵的任何一個，那麼都是適合於用Tablestore。

架構實踐

上面咱們介紹了Feed流系統的設計理論，具體到不一樣的類型中，會有不一樣的側重點，下面會逐一介紹。

朋友圈

朋友圈是一種典型的Feed流系統，關係是雙寫關係，關係有上限，排序按照時間，若是有我的持續產生垃圾內容，那就只能屏蔽掉TA，這一種類型就是典型的寫擴散模型。

咱們接下來會在文章《朋友圈類系統架構設計》中詳細介紹朋友圈類型Feed流系統的設計。

微博

微博也是一種很是典型的Feed流系統，但不一樣於朋友圈，關係是單向的，那麼也就會產生大V，這個時候就須要讀寫擴散模式，用讀擴散解決大V問題。同時，微博也是主動關注類型的產品，因此排序也只能是時間，若是按照推薦排序，那麼效果就會比較差。

接下里會在文章《微博類系統架構設計》中詳細介紹微博類型Feed流系統的設計。

頭條

頭條是最近幾年快速崛起的一款應用，在原有微博的Feed流系統上產生了進化，用戶不須要主動關注其餘人，只要初始瀏覽一些內容後，系統就會自動判斷出你的喜愛，而後後面再根據你的喜愛給你推薦你可能會喜愛的內容，訓練時間長了後，推送的內容都會是你最喜歡看的。

後面，咱們會在文章《頭條類系統架構設計》中詳細介紹頭條類型Feed流系統的設計。

私信

私信也算是一種簡單的Feed流系統，或者也能夠認爲是一種變相的IM，都是單對單的，沒有羣。咱們後面也會有一篇文章《私信類系統架構設計》中作詳細介紹。

總結

上面咱們介紹了Feed流系統的總體框架，主要是產品定義、同步、存儲、元數據、評論、贊、排序和搜索等內容，因爲篇幅有限，每一章節都介紹的比較簡單。讀者若是對某一部分看完後仍然有疑問，能夠繼續再文後提問，我會繼續去完善這篇文章，但願將來讀者看完這篇文章後，就能夠輕輕鬆鬆設計出一個億級規模的Feed流系統。

另外，咱們也歡迎有興趣的讀者一塊兒來完成這個系列，幫忙實現朋友圈、微博、頭條或者私信類型的文章，有任何問題都歡迎來討論。