譯者 | 劉汪洋

審校 | 重樓

微服務(wù)架構(gòu)以其可擴(kuò)展性、敏捷性和彈性深受青睞，但在實(shí)踐中，許多組織往往遭遇可能削弱這些優(yōu)勢(shì)的挑戰(zhàn)。本文聚焦于常見的微服務(wù)反模式，并結(jié)合實(shí)際經(jīng)驗(yàn)提供構(gòu)建高效、可擴(kuò)展微服務(wù)的實(shí)用建議。

要避免的微服務(wù)反模式

1.分布式單體

問(wèn)題

“分布式單體” 是指盡管系統(tǒng)形式上采用了微服務(wù)架構(gòu)，但服務(wù)之間高度耦合，以至于每次更新一個(gè)服務(wù)時(shí)，都需要同時(shí)調(diào)整或重新部署多個(gè)其他服務(wù)。這種設(shè)計(jì)實(shí)質(zhì)上延續(xù)了單體架構(gòu)的特點(diǎn)，只是將其組件分散在了不同的服務(wù)中，未能實(shí)現(xiàn)真正的微服務(wù)范式。

真實(shí)場(chǎng)景

例如，在一個(gè)包含支付服務(wù)、訂單服務(wù)和庫(kù)存服務(wù)的電子商務(wù)系統(tǒng)中，若這些服務(wù)彼此強(qiáng)依賴以完成用戶事務(wù)，則任何一項(xiàng)改動(dòng)都會(huì)導(dǎo)致連鎖反應(yīng)，要求其他服務(wù)同步更新或重新部署。盡管從外部看似為分布式系統(tǒng)，實(shí)際上這種耦合模式背離了微服務(wù)的核心原則。

實(shí)用解決方案

通過(guò)采用領(lǐng)域驅(qū)動(dòng)設(shè)計(jì) (DDD)，明確各服務(wù)的邊界上下文，從而實(shí)現(xiàn)職責(zé)分離。例如，將“支付服務(wù)”設(shè)計(jì)為獨(dú)立的自治域，僅通過(guò)定義清晰的 API 與其他服務(wù)交互，如“訂單服務(wù)”。同樣，訂單服務(wù)與庫(kù)存服務(wù)之間可以采用事件驅(qū)動(dòng)的設(shè)計(jì)模式（如基于 Kafka 的消息中間件），從而避免直接依賴。

專業(yè)建議

在系統(tǒng)遷移過(guò)程中，建議使用功能開關(guān)逐步引入新功能，同時(shí)確保與現(xiàn)有系統(tǒng)的向后兼容性。這種方法不僅降低了遷移風(fēng)險(xiǎn)，還能在實(shí)際應(yīng)用中驗(yàn)證新架構(gòu)的穩(wěn)定性和可行性。

2.跨服務(wù)共享數(shù)據(jù)

問(wèn)題

跨服務(wù)共享數(shù)據(jù)庫(kù)，尤其是允許多個(gè)服務(wù)對(duì)同一數(shù)據(jù)庫(kù)表進(jìn)行寫操作，會(huì)違反微服務(wù)架構(gòu)中關(guān)于服務(wù)自治的核心原則。這種設(shè)計(jì)增加了服務(wù)間的耦合度，使得對(duì)數(shù)據(jù)庫(kù)的任何更改都可能影響多個(gè)服務(wù)，從而削弱了微服務(wù)的獨(dú)立性和靈活性。

真實(shí)場(chǎng)景

在典型的 ERP 系統(tǒng)中，銷售服務(wù)和庫(kù)存服務(wù)可能需要訪問(wèn)同一產(chǎn)品表進(jìn)行數(shù)據(jù)寫入。例如，對(duì)產(chǎn)品信息的任何架構(gòu)調(diào)整或?qū)懖僮鳎紩?huì)引發(fā)連鎖反應(yīng)，導(dǎo)致相關(guān)服務(wù)發(fā)生故障。這種共享數(shù)據(jù)庫(kù)的模式不僅增加了系統(tǒng)的復(fù)雜性，還需要團(tuán)隊(duì)間密切協(xié)調(diào)，降低了開發(fā)效率。

實(shí)用解決方案

• 封裝數(shù)據(jù)庫(kù)邏輯：將數(shù)據(jù)庫(kù)訪問(wèn)邏輯封裝在特定的服務(wù)中，通過(guò)定義明確的 API 提供數(shù)據(jù)訪問(wèn)功能，避免其他服務(wù)直接訪問(wèn)數(shù)據(jù)庫(kù)。
• 引入只讀副本：使用只讀副本或緩存解決方案（如 Redis）滿足其他服務(wù)的讀取需求，同時(shí)確保寫操作僅限于擁有數(shù)據(jù)所有權(quán)的服務(wù)。
• 分布式數(shù)據(jù)庫(kù)隔離：最終目標(biāo)是為每個(gè)微服務(wù)提供獨(dú)立的數(shù)據(jù)庫(kù)，但在過(guò)渡期間，可以先定義明確的寫入權(quán)限，僅允許單一服務(wù)對(duì)特定表進(jìn)行寫操作，其他服務(wù)通過(guò) API 或查詢接口實(shí)現(xiàn)只讀訪問(wèn)。

實(shí)際挑戰(zhàn)

實(shí)現(xiàn)每個(gè)微服務(wù)獨(dú)立數(shù)據(jù)庫(kù)可能面臨較大的遷移成本，特別是在復(fù)雜系統(tǒng)中。作為折衷方案，可以在共享數(shù)據(jù)庫(kù)中采用“每個(gè)服務(wù)一個(gè)模式”的方法。具體而言，為每個(gè)微服務(wù)分配專屬的數(shù)據(jù)庫(kù)模式（Schema），其他服務(wù)無(wú)法直接訪問(wèn)這些模式中的數(shù)據(jù)，除非通過(guò)指定的 API。

陷阱

對(duì)于無(wú)模式數(shù)據(jù)庫(kù)（如 MongoDB），嚴(yán)格的 Schema 管理并不適用。然而，即便在無(wú)模式數(shù)據(jù)庫(kù)中，共享集合的微服務(wù)仍可能因?yàn)殡[式的數(shù)據(jù)協(xié)議產(chǎn)生耦合問(wèn)題。例如，一個(gè)服務(wù)以特定格式存儲(chǔ)數(shù)據(jù)，另一個(gè)服務(wù)卻期望以不同格式讀取這些數(shù)據(jù)，這種隱式契約會(huì)導(dǎo)致隱藏的兼容性問(wèn)題。因此，無(wú)模式數(shù)據(jù)庫(kù)中的服務(wù)間數(shù)據(jù)訪問(wèn)也應(yīng)通過(guò) API 抽象來(lái)避免直接依賴。

3.過(guò)度同步調(diào)用

問(wèn)題

過(guò)度同步調(diào)用（如通過(guò) REST 請(qǐng)求）可能導(dǎo)致系統(tǒng)性能下降。這種模式不僅增加了延遲，還提高了故障傳播的風(fēng)險(xiǎn)，尤其是在高流量場(chǎng)景下，會(huì)對(duì)系統(tǒng)的穩(wěn)定性和可擴(kuò)展性構(gòu)成嚴(yán)重挑戰(zhàn)。

真實(shí)場(chǎng)景

以客戶服務(wù)系統(tǒng)為例，處理每個(gè)客戶工單請(qǐng)求時(shí)，系統(tǒng)需要同步調(diào)用多個(gè)外部服務(wù)，如客戶服務(wù)以獲取客戶信息、賬戶服務(wù)以獲取賬戶詳情、通知服務(wù)以發(fā)送通知。在高并發(fā)流量下，這種設(shè)計(jì)模式可能導(dǎo)致網(wǎng)絡(luò)資源耗盡或服務(wù)響應(yīng)緩慢，嚴(yán)重影響用戶體驗(yàn)。

實(shí)用解決方案

• 減少同步調(diào)用：將多次 API 調(diào)用合并到單個(gè)聚合調(diào)用中，封裝在一個(gè)獨(dú)立的網(wǎng)關(guān)或終端節(jié)點(diǎn)后統(tǒng)一處理。這不僅減少了網(wǎng)絡(luò)請(qǐng)求，還提升了整體效率。
• 引入異步通信：采用異步通信機(jī)制（如 RabbitMQ 或 Kafka），尤其適用于通知服務(wù)等無(wú)需實(shí)時(shí)響應(yīng)的場(chǎng)景。異步模式可以有效解耦服務(wù)間的直接依賴。
• 緩存和非規(guī)范化：使用數(shù)據(jù)緩存或非規(guī)范化策略，預(yù)處理和存儲(chǔ)讀取優(yōu)化的數(shù)據(jù)，以減少對(duì)實(shí)時(shí)請(qǐng)求的依賴。例如，將相關(guān)的客戶和賬戶信息提前整合，以便直接響應(yīng)查詢請(qǐng)求，而無(wú)需多次調(diào)用其他服務(wù)。

專業(yè)建議

進(jìn)一步提升系統(tǒng)性能的策略包括構(gòu)建讀取優(yōu)化管道，通過(guò)變更數(shù)據(jù)捕獲 (CDC) 技術(shù)實(shí)時(shí)更新非規(guī)范化數(shù)據(jù)?？梢岳?Kafka 等流處理工具搭建數(shù)據(jù)流管道，當(dāng)數(shù)據(jù)源發(fā)生變更時(shí)，系統(tǒng)自動(dòng)生成非規(guī)范化的讀取副本。這種方法使用戶請(qǐng)求能夠直接訪問(wèn)預(yù)處理的數(shù)據(jù)，避免了實(shí)時(shí)解析復(fù)雜關(guān)系的開銷，從而顯著減少系統(tǒng)延遲和壓力。

4.服務(wù)邊界定義不明確

問(wèn)題

服務(wù)的職責(zé)范圍如果定義不清晰或存在重疊，會(huì)導(dǎo)致系統(tǒng)復(fù)雜化，使維護(hù)變得困難。同時(shí)，模糊的邊界關(guān)系也會(huì)引發(fā)所有權(quán)不明確的問(wèn)題，增加協(xié)調(diào)成本。

真實(shí)場(chǎng)景

在某電子商務(wù)系統(tǒng)中，假設(shè)一個(gè)“產(chǎn)品服務(wù)”負(fù)責(zé)處理產(chǎn)品創(chuàng)建、庫(kù)存更新以及客戶評(píng)論。由于這些職責(zé)相互獨(dú)立且功能復(fù)雜，將它們歸于同一服務(wù)會(huì)導(dǎo)致代碼臃腫、不相關(guān)邏輯糾纏，并最終使系統(tǒng)難以擴(kuò)展。

實(shí)用解決方案

采用領(lǐng)域驅(qū)動(dòng)設(shè)計(jì) (DDD) 原則，根據(jù)業(yè)務(wù)功能而非技術(shù)需求劃分服務(wù)。例如，將“庫(kù)存管理”“客戶評(píng)論”和“產(chǎn)品創(chuàng)建”拆分為獨(dú)立的微服務(wù)，確保每個(gè)服務(wù)專注于單一領(lǐng)域。清晰的功能分界能夠提高服務(wù)自治性，同時(shí)減少服務(wù)間的耦合。

專業(yè)建議

為每個(gè)微服務(wù)設(shè)立對(duì)應(yīng)的跨職能團(tuán)隊(duì)，確保領(lǐng)域知識(shí)與技術(shù)所有權(quán)一致。這樣不僅能夠快速響應(yīng)業(yè)務(wù)需求，還能減少因職責(zé)不明帶來(lái)的溝通障礙。

5.通信協(xié)議不一致

問(wèn)題

在微服務(wù)架構(gòu)中，如果通信協(xié)議沒(méi)有統(tǒng)一標(biāo)準(zhǔn)，頻繁混用 REST、gRPC 和 WebSockets 等協(xié)議，可能會(huì)造成維護(hù)困難，并增加集成復(fù)雜性。開發(fā)人員需要理解并適應(yīng)不同協(xié)議的特點(diǎn)，學(xué)習(xí)曲線陡峭，排障成本高。

真實(shí)場(chǎng)景

傳統(tǒng)微服務(wù)系統(tǒng)可能使用 REST 處理外部 API 請(qǐng)求，同時(shí)在某些內(nèi)部服務(wù)之間采用 gRPC，而事件通知?jiǎng)t依賴消息傳遞系統(tǒng)。這種多樣化的協(xié)議選擇缺乏一致性，開發(fā)人員必須深入理解每種技術(shù)的差異和用法，導(dǎo)致項(xiàng)目復(fù)雜度增加。

實(shí)用解決方案

根據(jù)使用場(chǎng)景對(duì)通信協(xié)議進(jìn)行標(biāo)準(zhǔn)化。例如：

• 外部接口：采用 REST 作為主要協(xié)議，便于跨平臺(tái)兼容。
• 內(nèi)部調(diào)用：對(duì)低延遲和高性能要求的場(chǎng)景，優(yōu)先選擇 gRPC。
• 事件驅(qū)動(dòng)架構(gòu)：利用消息隊(duì)列（如 RabbitMQ 或 Kafka）實(shí)現(xiàn)異步事件通知。

為團(tuán)隊(duì)提供清晰的文檔和工具以支持標(biāo)準(zhǔn)協(xié)議的實(shí)現(xiàn)，同時(shí)定期審查實(shí)際使用情況以確保遵循設(shè)計(jì)理念。

專業(yè)建議

采用服務(wù)網(wǎng)格（如 Istio 或 Linkerd），統(tǒng)一管理服務(wù)間的通信協(xié)議和流量控制。服務(wù)網(wǎng)格可以簡(jiǎn)化跨服務(wù)調(diào)用的配置，同時(shí)提高監(jiān)控和故障排除能力，幫助實(shí)現(xiàn)標(biāo)準(zhǔn)化和展示一致。

6.缺乏可觀察性

問(wèn)題

當(dāng)服務(wù)運(yùn)行狀況、交互方式和性能缺乏可見性時(shí)，診斷問(wèn)題的難度將大幅增加。這種情況會(huì)削弱系統(tǒng)的彈性和恢復(fù)能力，特別是在復(fù)雜的分布式系統(tǒng)中。

真實(shí)場(chǎng)景

例如，在一個(gè)支付系統(tǒng)中，如果某服務(wù)出現(xiàn)故障，這種問(wèn)題可能通過(guò)服務(wù)之間的交互鏈發(fā)生級(jí)聯(lián)效應(yīng)。然而，由于缺乏全局視角和系統(tǒng)級(jí)的監(jiān)控手段，定位根本原因往往需要開發(fā)人員手動(dòng)檢索和分析各服務(wù)的分散日志，導(dǎo)致問(wèn)題解決效率低下。

實(shí)用解決方案

• 分布式跟蹤：采用工具如 OpenTelemetry，通過(guò)跨服務(wù)傳播交易 ID，幫助開發(fā)人員追蹤請(qǐng)求在整個(gè)系統(tǒng)中的流轉(zhuǎn)路徑，快速發(fā)現(xiàn)問(wèn)題根源。
• 集中式日志管理：引入 ELK 堆棧（Elasticsearch、Logstash、Kibana）等集中式日志解決方案，將所有服務(wù)的日志集中到一個(gè)平臺(tái)，便于快速檢索和分析。
• 指標(biāo)采集與監(jiān)控：使用 Prometheus 等工具收集系統(tǒng)性能指標(biāo)，并通過(guò) Grafana 等可視化工具監(jiān)控服務(wù)運(yùn)行狀況。

專業(yè)建議

建議從基礎(chǔ)日志記錄開始，隨著系統(tǒng)復(fù)雜性增加，逐步引入分布式跟蹤和高級(jí)監(jiān)控功能。同時(shí)，設(shè)置預(yù)警閾值，結(jié)合監(jiān)控系統(tǒng)自動(dòng)發(fā)送告警通知，從被動(dòng)診斷轉(zhuǎn)向主動(dòng)預(yù)防。

7.硬編碼配置

問(wèn)題

硬編碼的配置（如數(shù)據(jù)庫(kù) URL、密鑰或服務(wù)終端節(jié)點(diǎn)）不僅會(huì)限制部署的靈活性，還可能造成嚴(yán)重的安全風(fēng)險(xiǎn)。配置的泄露可能導(dǎo)致敏感信息暴露甚至系統(tǒng)被攻擊。

真實(shí)場(chǎng)景

例如，生產(chǎn)環(huán)境的數(shù)據(jù)庫(kù)連接字符串直接硬編碼在源代碼中。如果開發(fā)人員將代碼提交到版本控制系統(tǒng)，該敏感信息可能意外暴露。此外，某些外部腳本（如自動(dòng)化工具）也可能包含硬編碼配置，增加了管理難度。

實(shí)用解決方案

• 外部化配置：將所有配置（如連接字符串和密鑰）從源代碼中移除，存儲(chǔ)在環(huán)境變量、配置管理系統(tǒng)（如 Consul）或 Kubernetes 的 ConfigMaps 和 Secrets 中。
• 自動(dòng)化管理：在 CI/CD 流水線中集成安全掃描工具，檢測(cè)代碼中的硬編碼配置，并在部署前阻止可能的安全風(fēng)險(xiǎn)。

專業(yè)建議

定期審核配置文件和密鑰的安全性，確保訪問(wèn)權(quán)限僅限必要范圍?？梢酝ㄟ^(guò)在 CI/CD 管道中集成自動(dòng)化腳本，在構(gòu)建源代碼之前掃描潛在的硬編碼敏感信息，避免人為錯(cuò)誤造成的安全漏洞。

8.忽視網(wǎng)絡(luò)可靠性和延遲

問(wèn)題

微服務(wù)架構(gòu)由于依賴分布式網(wǎng)絡(luò)通信，其穩(wěn)定性容易受到網(wǎng)絡(luò)故障和延遲的影響。如果未采取有效措施緩解網(wǎng)絡(luò)問(wèn)題，可能會(huì)引發(fā)服務(wù)掛起、超時(shí)甚至全系統(tǒng)失效。

真實(shí)場(chǎng)景

例如，當(dāng)一個(gè)服務(wù)調(diào)用外部支付提供商的 API 時(shí)，如果網(wǎng)絡(luò)請(qǐng)求超時(shí)且沒(méi)有超時(shí)保護(hù)或重試機(jī)制，下游服務(wù)可能被阻塞，進(jìn)而導(dǎo)致整個(gè)交易流程中斷。

實(shí)用解決方案

• 實(shí)施彈性模式：采用工具如 Resilience4j 實(shí)現(xiàn)斷路器模式，防止服務(wù)因頻繁失敗請(qǐng)求而過(guò)載；配置指數(shù)回退重試策略，以智能化地重新嘗試失敗的請(qǐng)求。
• 設(shè)置超時(shí)保護(hù)：定義合理的超時(shí)時(shí)間，避免請(qǐng)求長(zhǎng)時(shí)間掛起。
• 負(fù)載均衡：通過(guò)負(fù)載均衡器分散請(qǐng)求壓力，防止單一服務(wù)因過(guò)載而失效。

專業(yè)建議

引入服務(wù)網(wǎng)格（如 Istio）為系統(tǒng)提供內(nèi)置的彈性功能，如自動(dòng)流量控制和故障注入測(cè)試。通過(guò)模擬網(wǎng)絡(luò)延遲和故障場(chǎng)景，驗(yàn)證系統(tǒng)在極端情況下的可靠性。

9.API 版本控制不足

問(wèn)題

在缺乏有效版本控制的情況下，對(duì) API 進(jìn)行破壞性變更（如修改請(qǐng)求/響應(yīng)結(jié)構(gòu)或以非向后兼容的方式更新功能）可能導(dǎo)致依賴該 API 的客戶端應(yīng)用程序無(wú)法正常運(yùn)行。這種不兼容會(huì)引發(fā)緊急回滾或代價(jià)高昂的修復(fù)。

真實(shí)場(chǎng)景

假設(shè)一個(gè) REST API 更新了請(qǐng)求有效負(fù)載的結(jié)構(gòu)，但未通知客戶端開發(fā)團(tuán)隊(duì)。結(jié)果，多個(gè)客戶端應(yīng)用程序因調(diào)用失敗而中斷，進(jìn)而影響最終用戶體驗(yàn)。

實(shí)用解決方案

• 采用版本控制策略：對(duì) API 進(jìn)行顯式版本化，例如通過(guò) URL 路徑（如 /v1/resource）或 HTTP 頭信息明確區(qū)分不同版本。
• 管理?xiàng)売弥芷?/strong>：在引入新版本的同時(shí)，提供明確的遷移計(jì)劃和過(guò)渡期，避免強(qiáng)制客戶端立即調(diào)整。
• 清晰的變更通知：通過(guò)文檔和公告及時(shí)傳達(dá) API 的變更內(nèi)容，確保使用者了解和適應(yīng)。

專業(yè)建議

使用 OpenAPI 等工具自動(dòng)生成和管理 API 文檔，跟蹤變更歷史并簡(jiǎn)化開發(fā)人員對(duì)新版本的適應(yīng)過(guò)程。此外，考慮在 API 網(wǎng)關(guān)中添加版本路由邏輯，以同時(shí)支持舊版和新版 API，進(jìn)一步減少遷移帶來(lái)的沖擊。

10.為基礎(chǔ)設(shè)施問(wèn)題重新造輪子

問(wèn)題

嘗試自行開發(fā)服務(wù)發(fā)現(xiàn)、運(yùn)行狀況檢查或負(fù)載均衡等基礎(chǔ)設(shè)施功能，往往既耗費(fèi)資源，又增加了維護(hù)復(fù)雜性。這類定制解決方案容易出現(xiàn)兼容性問(wèn)題，并且占用了本應(yīng)聚焦于業(yè)務(wù)功能開發(fā)的時(shí)間和精力。

真實(shí)場(chǎng)景

例如，構(gòu)建一個(gè)自定義的服務(wù)發(fā)現(xiàn)工具，不僅需要處理多環(huán)境部署的復(fù)雜性，還可能隨著微服務(wù)數(shù)量增加而暴露出性能和兼容性問(wèn)題，最終造成運(yùn)營(yíng)負(fù)擔(dān)。

實(shí)用解決方案

• 使用標(biāo)準(zhǔn)化工具：采用經(jīng)過(guò)驗(yàn)證的開源或商用工具，如 Kubernetes，來(lái)處理服務(wù)發(fā)現(xiàn)、運(yùn)行狀況檢查和負(fù)載均衡等基礎(chǔ)設(shè)施需求。
• 借助服務(wù)網(wǎng)格：通過(guò)服務(wù)網(wǎng)格（如 Istio 或 Linkerd），實(shí)現(xiàn)跨服務(wù)的一致流量管理策略、運(yùn)行狀況監(jiān)控和故障注入測(cè)試，從而避免重復(fù)開發(fā)基礎(chǔ)設(shè)施功能。

專業(yè)建議

將團(tuán)隊(duì)的工程重點(diǎn)放在業(yè)務(wù)邏輯和客戶價(jià)值上，而非重新構(gòu)造已有的基礎(chǔ)設(shè)施組件。這種方法不僅減少了開發(fā)和維護(hù)成本，還可以利用社區(qū)和現(xiàn)成生態(tài)系統(tǒng)的支持來(lái)快速解決問(wèn)題。

結(jié)論

構(gòu)建可擴(kuò)展的微服務(wù)架構(gòu)既充滿機(jī)遇，也伴隨著挑戰(zhàn)。通過(guò)識(shí)別和解決常見的反模式（如分布式單體架構(gòu)、跨服務(wù)共享數(shù)據(jù)和過(guò)度同步調(diào)用），可以顯著提升服務(wù)的獨(dú)立性、彈性和擴(kuò)展能力。

在實(shí)際的項(xiàng)目設(shè)計(jì)中，約束條件往往需要我們?cè)诶碚撆c實(shí)踐之間找到平衡。例如，在數(shù)據(jù)分離中，可能需要臨時(shí)采用封裝的 API 訪問(wèn)共享數(shù)據(jù)；在選用 MongoDB 等靈活數(shù)據(jù)庫(kù)時(shí)，則需格外關(guān)注隱式依賴帶來(lái)的風(fēng)險(xiǎn)。微服務(wù)的成功在于明確的邊界定義、一致的通信標(biāo)準(zhǔn)以及強(qiáng)大的可觀察性能力。

根據(jù)實(shí)際情況，將技術(shù)決策與業(yè)務(wù)需求相結(jié)合，充分發(fā)揮微服務(wù)的優(yōu)勢(shì)，并有效規(guī)避常見陷阱。這種方法不僅有助于提升團(tuán)隊(duì)效率，還能為系統(tǒng)的長(zhǎng)期可持續(xù)性打下堅(jiān)實(shí)基礎(chǔ)。

作者介紹

劉汪洋，51CTO社區(qū)編輯，昵稱：明明如月，一個(gè)擁有 5 年開發(fā)經(jīng)驗(yàn)的某大廠高級(jí) Java 工程師。

原文標(biāo)題：10 Microservices Anti-Patterns to Avoid for Scalable Applications，作者：Abhishek Goswami