接著上一篇文章?一天開發(fā)完成了一個極簡版社區(qū)后端服務(wù)?，使用工具實戰(zhàn)一個微服務(wù)集群項目。

單體服務(wù)community-single拆分為微服務(wù)具體過程

社區(qū)后端服務(wù)community-single采用單體web應(yīng)用架構(gòu)，為了應(yīng)對需求增加，造成功能越來越復(fù)雜，代碼維護和開發(fā)變得困難的問題，把community-single拆分成多個微服務(wù)，下面是拆分微服務(wù)具體步驟：

第一步是進行系統(tǒng)分析和設(shè)計。首先確定哪些功能模塊適合獨立作為微服務(wù)，需要對單體服務(wù)community-single進行了仔細的功能分解，將其劃分為幾個關(guān)鍵的領(lǐng)域，分為用戶服務(wù)(user)、關(guān)系服務(wù)(relation)和內(nèi)容創(chuàng)作服務(wù)(creation)三個獨立的服務(wù)。用戶服務(wù)負責用戶注冊登錄等功能，關(guān)系服務(wù)負責好友關(guān)系管理等，內(nèi)容創(chuàng)作服務(wù)負責帖子創(chuàng)建、評論、點贊、收藏等功能。這些領(lǐng)域代表了系統(tǒng)的核心功能，并且在不同的領(lǐng)域之間存在較強的邏輯隔離。

第二步是定義服務(wù)接口。每個微服務(wù)需要定義清晰的RPC接口供外部調(diào)用，接口需要指定輸入輸出的數(shù)據(jù)結(jié)構(gòu)。每個服務(wù)開發(fā)團隊需要根據(jù)業(yè)務(wù)設(shè)計自己的接口并完成接口文檔。

第三步是設(shè)計集群架構(gòu)。引入了一個rpc網(wǎng)關(guān)服務(wù)(community_gw)，rpc網(wǎng)關(guān)服務(wù)作為所有微服務(wù)的入口，負責路由請求和負載均衡，它可以根據(jù)請求的路由信息將請求轉(zhuǎn)發(fā)給相應(yīng)的微服務(wù)。此外，rpc網(wǎng)關(guān)服務(wù)還提供了身份驗證、授權(quán)和安全性等共享功能，以確保系統(tǒng)的安全性和一致性，這種架構(gòu)可以提高整體的擴展性。

第四步是數(shù)據(jù)遷移。單體服務(wù)community-single使用的單一數(shù)據(jù)庫，現(xiàn)在需要將數(shù)據(jù)按服務(wù)拆分，遷移至每個微服務(wù)自己的數(shù)據(jù)存儲中。這里用戶服務(wù)、關(guān)系服務(wù)、創(chuàng)作服務(wù)使用獨立的MySQL，實現(xiàn)各自的數(shù)據(jù)隔離。

第五步是開發(fā)、測試、部署微服務(wù)。在拆分后的微服務(wù)集群中，每個微服務(wù)都可以獨立進行。團隊成員可以專注于自己領(lǐng)域的開發(fā)工作，并且可以根據(jù)需求對各個微服務(wù)進行水平擴展，以滿足不同的性能需求。此外，微服務(wù)架構(gòu)還提供了更好的可擴展性，提供持續(xù)集成和持續(xù)交付(CI/CD)，以快速部署和發(fā)布新的功能和更新。微服務(wù)上線后，需要全面測試各個微服務(wù)的功能，確保拆分后的服務(wù)可以正常運行、RPC調(diào)用正常、滿足預(yù)期功能。

最后是流量遷移。當微服務(wù)架構(gòu)正常運行后，將外部流量逐步遷移至新的RPC網(wǎng)關(guān)層，停止對community-single的訪問，完成從單體架構(gòu)到微服務(wù)架構(gòu)的過渡。后端服務(wù)的擴展和升級將主要在微服務(wù)層進行。

通過上述步驟，將單體服務(wù)community-single拆分為微服務(wù)是一個復(fù)雜而耗時的過程，通過系統(tǒng)分析、功能拆分、技術(shù)選型、API設(shè)計和遷移策略等步驟，實現(xiàn)系統(tǒng)的微服務(wù)化，并提升系統(tǒng)的可擴展性、可靠性和性能。微服務(wù)架構(gòu)也帶來了分布式事務(wù)、運維成本增加等新的挑戰(zhàn)，需要綜合考慮多個因素。通過持續(xù)的評估和優(yōu)化，可以不斷提升系統(tǒng)的靈活性和可維護性，以適應(yīng)不斷變化的業(yè)務(wù)需求。

community-cluster 介紹

community-cluster是由?gRPC服務(wù)?和?rpc網(wǎng)關(guān)服務(wù)?這兩種服務(wù)類型組成，gRPC服務(wù)是各個功能的實現(xiàn)模塊，rpc網(wǎng)關(guān)服務(wù)主要作用是轉(zhuǎn)發(fā)請求給gRPC服務(wù)和組裝數(shù)據(jù)。community-cluster服務(wù)集群由工具sponge搭建，sponge生成gRPC服務(wù)和rpc網(wǎng)關(guān)服務(wù)代碼時都會自動剝離業(yè)務(wù)邏輯與非業(yè)務(wù)邏輯兩部分代碼，剝離業(yè)務(wù)邏輯與非業(yè)務(wù)邏輯的好處是讓開發(fā)者聚焦在核心業(yè)務(wù)邏輯代碼中，極大的減小搭建微服務(wù)集群的難度，減少人工編寫大量代碼。點擊查看community-cluster的完整項目代碼，框架圖如下圖所示：

gRPC服務(wù)代碼組成結(jié)構(gòu)基于grpc封裝，包括了豐富的服務(wù)治理插件、構(gòu)建、部署腳本，gRPC服務(wù)代碼組成結(jié)構(gòu)如下圖所示：

從圖1可以看出，開發(fā)一個完整的微服務(wù)聚焦在定義數(shù)據(jù)表、定義api接口、在模板代碼中編寫具體業(yè)務(wù)邏輯代碼這3個節(jié)點上，而這3個節(jié)點代碼在單體web服務(wù)community-single已經(jīng)存在，不需要重新編寫，直接把這些代碼移植過來即可，也就是蛋黃(核心業(yè)務(wù)邏輯代碼)保持不變，只需換蛋殼(web框架換成gRPC框架)和蛋白(http handler相關(guān)代碼換成rpc service相關(guān)代碼)，使用工具sponge，很容易完成web服務(wù)到gRPC服務(wù)的轉(zhuǎn)換。

rpc網(wǎng)關(guān)服務(wù)代碼基于gin封裝，包括了豐富的服務(wù)治理插件、構(gòu)建、部署腳本，rpc網(wǎng)關(guān)服務(wù)代碼組成結(jié)構(gòu)如下圖所示：

從圖2可以看出，開發(fā)一個完整rpc網(wǎng)關(guān)服務(wù)聚焦在定義api接口、在模板代碼中編寫具體業(yè)務(wù)邏輯代碼這2個節(jié)點上，其中定義api接口在單體web服務(wù)community-single已經(jīng)存在，不需要重新編寫，復(fù)制proto文件過來就可以使用。

這是單體web服務(wù)和微服務(wù)集群依賴的proto文件對比圖，左邊是單體web服務(wù)依賴的proto文件，所有proto文件都在同一個服務(wù)中。右邊是微服務(wù)依賴的proto文件，根據(jù)各個gRPC服務(wù)依賴自己的proto文件。

在rpc網(wǎng)關(guān)服務(wù)中，如果需要從多個微服務(wù)中獲取的數(shù)據(jù)組裝成一個新的api接口，把這個組裝的新api接口描述信息填寫到community_gw.proto文件中。

下面使用工具sponge從0開始到完成微服務(wù)集群過程，開發(fā)過程依賴工具sponge，需要先安裝sponge，點擊查看安裝說明。

創(chuàng)建一個目錄community-cluster，把各個獨立微服務(wù)代碼移動到這個目錄下。

gRPC服務(wù)

創(chuàng)建user、relation、creation服務(wù)

進入sponge的UI界面，點擊左邊菜單欄【Protobuf】--> 【RPC類型】-->【創(chuàng)建rpc項目】，填寫參數(shù)，分別生成三個微服務(wù)代碼。

創(chuàng)建user服務(wù)

這是從單體服務(wù)community-single復(fù)制過來的proto文件user.proto，用來快速生成用戶(user)服務(wù)代碼，如下圖所示：

解壓代碼，把目錄名稱改為user，然后把user目錄移動community-cluster目錄下。

創(chuàng)建relation服務(wù)

這是從單體服務(wù)community-single復(fù)制過來的proto文件relation.proto，用來快速生成關(guān)系(relation)服務(wù)，如下圖所示：

解壓代碼，把目錄名稱改為relation，然后把relation目錄移動community-cluster目錄下。

創(chuàng)建creation服務(wù)

這是從單體服務(wù)community-single復(fù)制過來的proto文件post.proto、comment.proto、like.proto、collect.proto，快速生成創(chuàng)作(creation)服務(wù)，如下圖所示：

解壓代碼，把目錄名稱改為creation，然后把creation目錄移動community-cluster目錄下。

經(jīng)過簡單的界面操作就創(chuàng)建了三個gRPC服務(wù)(user、relation、creation)，也就是完成了各個gRPC服務(wù)各自的圖1中蛋殼部分，接下來完成圖1中蛋白和蛋黃兩部分代碼。

編寫user、relation、creation服務(wù)的業(yè)務(wù)邏輯代碼

從上面圖1中微服務(wù)雞蛋模型解剖圖看出，經(jīng)過sponge剝離后的業(yè)務(wù)邏輯代碼只包括蛋白和蛋黃兩部分，編寫業(yè)務(wù)邏輯代碼都是圍繞這兩部分開展。

編寫user服務(wù)業(yè)務(wù)邏輯代碼

分三個步驟編寫user服務(wù)業(yè)務(wù)邏輯代碼。

第一步 生成模板代碼，進入項目user目錄，打開終端，執(zhí)行命令：

make proto

這個命令生成了service模板代碼、錯誤碼、rpc客戶端測試代碼，這些代碼對應(yīng)圖1中蛋白部分。

• service模板代碼，在internal/service目錄下，文件名稱與proto文件名一致，后綴名是_login.go，文件里面的方法函數(shù)與proto文件定義的rpc方法名一一對應(yīng)，默認每個方法函數(shù)下有簡單的使用示例，只需在每個方法函數(shù)里面編寫具體的邏輯代碼。

• 接口錯誤碼，在internal/ecode目錄下，文件名稱與proto文件名一致，后綴是_rpc.go，文件里面的默認錯誤碼變量與proto文件定義的rpc方法名一一對應(yīng)，在這里添加或更改業(yè)務(wù)相關(guān)的錯誤碼，注意錯誤碼不能重復(fù)，否則會觸發(fā)panic。

• rpc客戶端測試代碼，在internal/service目錄下，文件名稱與proto文件名一致，后綴是_client_test.go，文件里面的方法函數(shù)與proto文件定義的rpc方法名一一對應(yīng)，填寫參數(shù)，就可以每個rpc方法。

第二步 遷移dao代碼，把單體web服務(wù)community-single目錄中的internal/model、internal/cache、internal/dao、,internal/ecode這四個目錄下user開頭的代碼文件，復(fù)制到user服務(wù)目錄下，復(fù)制后的目錄和文件名稱不變。復(fù)制的這些代碼對應(yīng)圖1中蛋白部分。

第三步 遷移具體邏輯代碼，把單體web服務(wù)community-single代碼文件internal/handler/user_logic.go各個方法函數(shù)下的具體邏輯代碼，復(fù)制到user服務(wù)代碼文件internal/service/user_logic.go同名的函數(shù)下。這些代碼是圖1中蛋黃的編寫業(yè)務(wù)邏輯代碼部分。

編寫relation服務(wù)業(yè)務(wù)邏輯代碼

分三個步驟編寫relation服務(wù)業(yè)務(wù)邏輯代碼，參考上面user服務(wù)的三個步驟。

編寫creation服務(wù)業(yè)務(wù)邏輯代碼

分三個步驟編寫creation服務(wù)業(yè)務(wù)邏輯代碼，參考上面user服務(wù)的三個步驟。

測試user、relation、creation服務(wù)的rpc方法

測試user服務(wù)的rpc方法

編寫了業(yè)務(wù)邏輯代碼后，啟動服務(wù)來測試rpc方法，在第一次啟動服務(wù)前，先打開配置文件(user/configs/user.yml)設(shè)置mysql和redis地址、設(shè)置grpc和grpcClient相關(guān)參數(shù)，然后執(zhí)行命令編譯啟動服務(wù)：

# 編譯、運行服務(wù)make run

在goland IDE打開user服務(wù)代碼，進入user/internal/service目錄，找到后綴為_client_test.go的代碼文件，在各個rpc方法填寫參數(shù)后進行測試。

測試relation服務(wù)的rpc方法

測試relation服務(wù)的rpc方法，請參考上面user服務(wù)的測試rpc方法。

測試creation服務(wù)的rpc方法

測試creation服務(wù)的rpc方法，請參考上面user服務(wù)的測試rpc方法。

rpc網(wǎng)關(guān)服務(wù)

完成了user、relation、creation這三個服務(wù)后，接著需要完成rpc網(wǎng)關(guān)服務(wù)community_gw，community_gw作為user、relation、creation服務(wù)的統(tǒng)一入口。

創(chuàng)建community_gw服務(wù)

進入sponge的UI界面，點擊左邊菜單欄【Protobuf】--> 【W(wǎng)eb類型】-->【創(chuàng)建rpc網(wǎng)關(guān)項目】，填寫一些參數(shù)生成rpc網(wǎng)關(guān)服務(wù)代碼。

這是從單體服務(wù)community-single復(fù)制過來的proto文件user_gw.proto、relation_gw.proto、post_gw.proto、comment_gw.proto、like_gw.proto、collect_gw.proto，快速創(chuàng)建rpc網(wǎng)關(guān)服務(wù)community_gw，如下圖所示：

解壓代碼，把目錄名稱改為community_gw。

因為community_gw服務(wù)作為請求入口，使用rpc方式與user、relation、creation通信，因此需要生成連接user、relation、creation服務(wù)的代碼。進入sponge的UI界面，點擊左邊菜單欄【Public】-->【生成rpc服務(wù)連接代碼】，填寫一些參數(shù)生成rpc服務(wù)連接代碼，如下圖所示：

解壓代碼，把目錄internal移動到community_gw服務(wù)目錄下。

同時把user、relation、creation三個服務(wù)的proto文件復(fù)制到community_gw的api目錄下，如下列表所示。其中community_gw的v1目錄下的proto文件是定義http的api接口信息，建議統(tǒng)一約定后綴名_gw.proto。

通過簡單的操作就完成創(chuàng)建了rpc網(wǎng)關(guān)服務(wù)community_gw。

編寫community_gw服務(wù)的業(yè)務(wù)邏輯代碼

從上面圖2中rpc網(wǎng)關(guān)代碼雞蛋模型解剖圖看出，經(jīng)過sponge剝離后的業(yè)務(wù)邏輯代碼只包括蛋白和蛋黃兩部分，編寫業(yè)務(wù)邏輯代碼都是圍繞這兩部分開展。

編寫與proto文件相關(guān)的業(yè)務(wù)邏輯代碼

進入項目community-gw目錄，打開終端，執(zhí)行命令：

這個命令是根據(jù)community_gw/api/community_gw/v1目錄下的proto文件生成了service模板代碼、注冊路由代碼、api接口錯誤碼、swagger文檔這四個部分代碼，也就是圖2中的蛋白部分。

(1)?生成的service模板代碼，在community_gw/internal/service目錄下，文件名稱與proto文件名一致，后綴名是_logic.go，名稱分別有：

collect_gw_logic.go,?comment_gw_logic.go,?like_gw_logic.go,?post_gw_logic.go,?relation_gw_logic.go,?user_gw_logic.go

在這些文件里面的方法函數(shù)與proto文件定義的rpc方法名一一對應(yīng)，每個方法函數(shù)下有默認的使用示例，只需要簡單調(diào)整就可以調(diào)用user、relation、creation服務(wù)端的rpc方法。上面那些文件代碼是已經(jīng)編寫具體邏輯之后的代碼。

(2)?生成注冊路由代碼，在community_gw/internal/routers目錄下，文件名稱與proto文件名一致，后綴名是_service.pb.go，名稱分別有：

collect_gw_service.pb.go,?comment_gw_service.pb.go,?like_gw_service.pb.go,?post_gw_service.pb.go,?relation_gw_service.pb.go,?user_gw_service.pb.go

在這些文件里面的設(shè)置api接口的中間件，例如jwt鑒權(quán)，每個接口都已經(jīng)存在中間件模板代碼，只需要取消注釋代碼就可以使中間件生效，只需要取消注釋代碼就可以使中間件生效，支持路由分組和單獨路由來設(shè)置gin中間件。

(3)?生成接口錯誤碼，在community_gw/internal/ecode目錄下，文件名稱與proto文件名一致，后綴是_rpc.go，名稱分別有：

collect_gw_rpc.go,?comment_gw_rpc.go,?like_gw_rpc.go,?post_gw_rpc.go,?relation_gw_rpc.go,?user_gw_rpc.go

在這些文件里面的默認錯誤碼變量與proto文件定義的rpc方法名一一對應(yīng)，在這里添加或更改業(yè)務(wù)相關(guān)的錯誤碼，注意錯誤碼不能重復(fù)，否則會觸發(fā)panic。

注： 如果調(diào)用的rpc方法本身包含了錯誤碼，可以直接返回該錯誤碼。

(4)?生成swagger文檔，在community_gw/docs目錄下，名稱為apis.swagger.json

如果在proto文件添加或更改了api接口，需要重新再執(zhí)行一次命令make proto更新代碼，會發(fā)現(xiàn)在community_gw/internal/handler、community_gw/internal/routers、community_gw/internal/ecode目錄下出現(xiàn)后綴名為日期時間的代碼文件，打開文件，把新增或修改部分代碼復(fù)制到同名文件代碼中即可。復(fù)制完新增代碼后，執(zhí)行命令make clean清除這些日期后綴文件。

make proto命令生成的代碼是用來連接web框架代碼和業(yè)務(wù)邏輯核心代碼的橋梁，也就是蛋白部分，這種分層生成代碼的好處是減少編寫代碼。

測試api接口

編寫了業(yè)務(wù)邏輯代碼后，啟動服務(wù)測試api接口，在第一次啟動服務(wù)前，先打開配置文件(community_gw/configs/community_gw.yml)設(shè)置連接rpc服務(wù)配置信息，如下所示：

執(zhí)行命令編譯啟動服務(wù)：

在瀏覽器訪問?http://localhost:8080/apis/swagger/index.htm?，進入swagger界面，如下圖所示：

從圖中看到有些api接口右邊有一把鎖標記，表示請求頭會攜帶鑒權(quán)信息Authorization，服務(wù)端接收到請求是否做鑒權(quán)，由服務(wù)端決定，如果服務(wù)端需要做鑒權(quán)，可以在community_gw/internal/routers目錄下后綴文件為_service.pb.go文件中設(shè)置，也就是取消鑒權(quán)的注釋代碼，使api接口的鑒權(quán)中間件生效。

服務(wù)治理

gRPC服務(wù)(user、relation、creation)和rpc網(wǎng)關(guān)服務(wù)(community-gw)都包含了豐富的服務(wù)治理插件(日志、限流、熔斷、鏈路跟蹤、服務(wù)注冊與發(fā)現(xiàn)、指標采集、性能分析、資源統(tǒng)計、配置中心)，有些服務(wù)治理插件默認是關(guān)閉的，根據(jù)實際需要開啟使用。

除了服務(wù)本身提供的治理插件，也可以使用自己的服務(wù)治理插件，添加自己的服務(wù)治理插件說明：

• 對于微服務(wù)(user、relation、creation)，在代碼文件服務(wù)名稱/internal/server/grpc.go里添加自己的插件，如果你的服務(wù)治理插件(攔截器)屬于unary類型，添加到unaryServerOptions函數(shù)里面。如果你的服務(wù)治理插件(攔截器)屬于stream類型，添加到streamServerOptions函數(shù)里面。

• 對于rpc網(wǎng)關(guān)服務(wù)community-gw，在代碼文件community-gw/internal/routers/routers.go里添加自己的插件(gin中間件)。

下面是默認的服務(wù)治理插件開啟和設(shè)置說明，統(tǒng)一在各自服務(wù)配置文件服務(wù)名稱/configs/服務(wù)名稱.yml進行設(shè)置。

日志

日志插件(zap)默認是開啟的，默認是輸出到終端，默認輸出日志格式是console，可以設(shè)置輸出格式為json，設(shè)置日志保存到指定文件，日志文件切割和保留時間。

在配置文件里的字段logger設(shè)置：

限流

限流插件默認是關(guān)閉的，自適應(yīng)限流，不需要設(shè)置其他參數(shù)。

在配置文件里的字段enableLimit設(shè)置：

熔斷

熔斷插件默認是關(guān)閉的，自適應(yīng)熔斷，支持自定義錯誤碼(默認500和503)觸發(fā)熔斷，在internal/routers/routers.go設(shè)置。

在配置文件里的字段enableCircuitBreaker設(shè)置：

鏈路跟蹤

鏈路跟蹤插件默認是關(guān)閉的，鏈路跟蹤依賴jaeger服務(wù)。

在配置文件里的字段enableTrace設(shè)置：

在jaeger界面上查看鏈路跟蹤信息文檔說明。

服務(wù)注冊與發(fā)現(xiàn)

服務(wù)注冊與發(fā)現(xiàn)插件默認是關(guān)閉的，支持consul、etcd、nacos三種類型。

在配置文件里的字段registryDiscoveryType設(shè)置：

指標采集

指標采集功能默認是開啟的，提供給prometheus采集數(shù)據(jù)，默認路由是/metrics。

在配置文件里的字段enableMetrics設(shè)置：

使用prometheus和grafana采集指標和監(jiān)控服務(wù)的文檔說明。

性能分析

性能分析插件默認是關(guān)閉的，采集profile的默認路由是/debug/pprof，除了支持go語言本身提供默認的profile分析，還支持io分析，路由是/debug/pprof/profile-io。

在配置文件里的字段enableHTTPProfile設(shè)置：

通過路由采集profile進行性能分析方式，通常在開發(fā)或測試時使用，如果線上開啟會有一點點性能損耗，因為程序后臺一直定時記錄profile相關(guān)信息。sponge生成的服務(wù)本身對此做了一些改進，平時停止采集profile，用戶主動觸發(fā)系統(tǒng)信號時才開啟和關(guān)閉采集profile，采集profile保存到/tmp/服務(wù)名稱_profile目錄，默認采集為60秒，60秒后自動停止采集profile，如果只想采集30秒，發(fā)送第一次信號開始采集，大概30秒后發(fā)送第二次信號表示停止采集profile，類似開關(guān)一樣。

這是采集profile操作步驟：

注：只支持linux、darwin系統(tǒng)。

資源統(tǒng)計

資源統(tǒng)計插件默認是開啟的，默認每分鐘統(tǒng)計一次并輸出到日志，資源統(tǒng)計了包括系統(tǒng)和服務(wù)本身這兩部分的cpu和內(nèi)存相關(guān)的數(shù)據(jù)。

資源統(tǒng)計還包含了自動觸發(fā)采集profile功能，當連續(xù)3次統(tǒng)計本服務(wù)的CPU或內(nèi)存平均值，CPU或內(nèi)存平均值占用系統(tǒng)資源超過80%時，自動觸發(fā)采集profile，默認采集為60秒，采集profile保存到/tmp/服務(wù)名稱_profile目錄，從而實現(xiàn)了自適應(yīng)采集profile，比通過人工發(fā)送系統(tǒng)信號來采集profile又改進了一步。

在配置文件里的字段enableHTTPProfile設(shè)置：

配置中心

目前支持nacos作為配置中心，配置中心文件configs/user_cc.yml，配置內(nèi)容如下：

而服務(wù)的配置文件configs/user.yml復(fù)制到nacos界面上配置。使用nacos配置中心，啟動服務(wù)命令需要指定配置中心文件，命令如下：

使用nacos作為配置中心的文檔說明。

服務(wù)壓測

壓測服務(wù)時使用的一些工具：

• http壓測工具wrk或go-stress-testing。

• 服務(wù)開啟指標采集功能，使用prometheus采集服務(wù)指標和系統(tǒng)指標進行監(jiān)控。

• 服務(wù)本身的自適應(yīng)采集profile功能。

壓測指標：

• 并發(fā)度: 逐漸增加并發(fā)用戶數(shù)，找到服務(wù)的最大并發(fā)度，確定服務(wù)能支持的最大用戶量。

• 響應(yīng)時間: 關(guān)注并發(fā)用戶數(shù)增加時，服務(wù)的平均響應(yīng)時間和響應(yīng)時間分布情況。確保即使在高并發(fā)下，響應(yīng)時間也在可接受范圍內(nèi)。

• 錯誤率: 觀察并發(fā)增加時，服務(wù)出現(xiàn)錯誤或異常的概率。使用壓測工具進行長時間并發(fā)測試，統(tǒng)計各并發(fā)級別下的錯誤數(shù)量和類型。

• 吞吐量: 找到服務(wù)的最大吞吐量，確定服務(wù)在高并發(fā)下可以支持的最大請求量。這需要不斷增加并發(fā)，直到找到吞吐量飽和點。

• 資源利用率: 關(guān)注并發(fā)增加時，CPU、內(nèi)存、磁盤I/O、網(wǎng)絡(luò)等資源的利用率，找到服務(wù)的資源瓶頸。

• 瓶頸檢測: 通過觀察高并發(fā)情況下服務(wù)的性能指標和資源利用率，找到系統(tǒng)和服務(wù)的硬件或軟件瓶頸，以便進行優(yōu)化。

• 穩(wěn)定性: 長時間高并發(fā)運行可以檢測到服務(wù)存在的潛在問題，如內(nèi)存泄露、連接泄露等，確保服務(wù)穩(wěn)定運行。這需要較長時間的并發(fā)壓測，觀察服務(wù)運行指標。

對服務(wù)進行壓測，主要是為了評估其性能，確定能支持的最大并發(fā)和吞吐量，發(fā)現(xiàn)當前的瓶頸，并檢測服務(wù)運行的穩(wěn)定性，以便進行優(yōu)化或容量規(guī)劃。

總結(jié)

本文介紹了把單體服務(wù)community-single拆分為微服務(wù)集群community-cluster的具體實踐過程，微服務(wù)集群包括了用戶服務(wù)(user)、關(guān)系服務(wù)(relation)和內(nèi)容創(chuàng)作服務(wù)(creation)三個獨立的服務(wù)，一個微服務(wù)入口的網(wǎng)關(guān)服務(wù)(community_gw)，這些服務(wù)代碼(圖1和圖2中的蛋殼和蛋白部分)都是由工具sponge生成，核心業(yè)務(wù)邏輯代碼直接手動無縫移植過來即可。

使用工具sponge很容易搭建出一個的微服務(wù)集群，微服務(wù)集群優(yōu)點：

• 高性能：基于 Protobuf 的高性能通信協(xié)議，同時具備高并發(fā)處理和低延遲的特點。

• 可擴展性：豐富的插件和組件機制，開發(fā)者可以根據(jù)實際需求定制和擴展框架功能。

• 高可靠性：提供了服務(wù)注冊和發(fā)現(xiàn)、限流、熔斷、鏈路、監(jiān)控告警等功能，提升了微服務(wù)的可靠性。