前言
在若干次前的一場面試，面試官看我做過 python爬蟲/後端 的工作，順帶問了我些後端相關的問題：你覺得什麼是後端？
送命題。當時腦瓦特了，答曰：邏輯處理和數據增刪改查。。。
當場被懟得體無完膚，羞愧難當。事後再反思這問題，結合資料總結了一下。發現自己學過的 Redis、 Elasticsearch和 DNS等其實都屬於後端知識體系範疇。
在本文中，我將嘗試總結前端須知的後端體系入門。
無論你的動機是什麼，這個體系裡都有你想要了解或學習的東西：
- 存儲和服務如何結合在一起？
- 什麼時候（或為什麼）我需要用到這個？
- 全棧之路該怎麼走？
- 各技術的主流框架選擇
本文目錄：
- Web / Application Servers
- 負載均衡器: Load Balancer
- 域名解析系統，DNS
- HTTPS / SSL證書
- 數據庫，Database
- Blob / 文件存儲
- 內容分發網絡（CDN）
- 緩存服務：Caching Service
- 消息隊列：Message queue
1、Web/ApplicationServers
- WebServers服務器：Web服務器，使用 http協議向Web提供內容。
- ApplicationServers：應用程序服務器，託管並公開業務邏輯和進程。
1.1 服務器端語言
可以使用不同的服務器端語言編寫代碼：
- 例如 Node.js，Python，PHP，Java，C＃或 Ruby。
- 每種語言都有自己的“Web框架”（例如基於 Java 的 Spring，基於 Ruby 的 Rails，基於C＃的ASP.NET MVC或基於Node.js的Express）。
- 這些框架使開發人員能夠編寫更少的代碼來處理數據請求。
1.2 後端語言選擇
而事實上，每個後端語言都有不一樣的特性，也都有各自的擁護者。哪一個語言最適合做為後端語言的入門一直都是沒有定論的問題。但為了讓我們可以對各語言有一個很簡單的概念，以下整理了各語言較常被提及的特色、在開發上比較被人詬病的點，以及有什麼樣的網站是透過該語言開發的：
PHP：
- 使用者多，算是最普及的後端語言。
- 簡單易學，但因一些古老的設計飽受批評。
- 網站範例：Facebook、 Wordpress、新浪微博。
Java：
- 老牌語言，開發統治者。國內外工作需求穩定，應用層面廣。
- 開發相較起來較慢，沒那麼適合新手。
- 網站範例：Linkedin、 Amazon、淘寶。
Ruby：
- 開發快速，國內外很多 bootcamp 都以此語言教後端。
- 適不適合新手學飽受爭議。
- 網站範例：Airbnb、 Twitter。
Python:
- 語法簡單易學，數據分析與資料探勘相關應用多。
- 單獨使用 Python 相較起來運行性能較差。
- 網站範例：Instagram、 Reddit、知乎。
JavaScript(Node.js):
- 前端後端都可用 JS，高併發的情況執行效率極高
- 不適合 CPU 密集的應用
- 初創型企業首選
- 網站範例：Yahoo、 Walmart
Go:
- Google力推，有很完善的標準庫，效能強大堪比C系列。
- 目前學習資源較少（感謝偉大B站的付出，真香）
- 網站範例：Google、 Youtube、嗶哩嗶哩、頭條、騰訊雲
1.2 Web服務器
即 WebServer，除了託管自定義應用程序代碼之外，一些Web應用程序體系結構還使用“Web服務器進程”，例如 ApacheHTTPServer或 Nginx。這些服務器進程將在訪問後端代碼之前攔截客戶端請求。使用它們有以下幾個原因：
- 快速重定向某些請求而不必通過後端代碼執行此操作（狀態碼404頁面）。
- 存儲在Web服務器的文件系統上的靜態內容（例如圖像， CSS， JS）比通過後端代碼訪問更快。
- 某些服務器端語言（例如 PHP）沒有內置的生產級 Web服務器，因此需要通過專用的 Web服務器進程啟動。
至此，會引出一個疑問： Apache、 Nginx、 Tomcat和 Node.js四者的區別是什麼？
引用：apache、node.js、nginx、tomcat誰能幫我捋一捋關係？
是一類東西，又不是一類東西。
首先它們都能創建 Web服務器，但是他們關注的點不一樣。
- Tomcat 只能跟 Java配合， Node.js只能跟 JavaScript。
- Apache 能和其他語言配合（通常跟 PHP 配合居多），但需要藉助不同的模塊。
- Nginx則是通過端口轉發，所以 Apache和 Nginx可以和各種編程語言一起使用
- Nginx和 Apache是純 web服務器，不具備解析動態語言（比如php文件和js文件）的能力.
- Tomcat和 Node.js 能夠解析這些腳本語言，提供應用服務， WebServer算是附加的功能。
1.3 web服務器的形式（載體）
安裝這些工具和後端項目的 Web服務器計算機，本身可以採用以下幾種形式：
- 一臺物理機器
- 虛擬專用服務器，即我們通常所說的VPS（例如華為雲，阿里雲等）
VPS實際上是被劃分為幾個部分的獨立服務器，每個部分作為單獨的VPS服務器進行銷售和使用。也就是說，它是一臺可運行多個Web應用程序(網站、軟件等)的相對獨立的機器，每個用戶擁有部分資源。
託管虛擬機實例（例如AWS EC2，Google Compute Engine）
平臺即服務（PaaS）主機，雲服務提供商（例如Heroku，AWS Elastic Beanstalk）
VPS是基於軟件層的虛擬化技術,具體來說就是操作系統的虛擬化, VM是基於硬件層的虛擬化技術, VM主機使用 vmware server搭建。
1.4 Dokcer，虛擬機與物理機
docker容器與虛擬機有什麼區別？
用個類比來極簡說明一下：
1、物理機是這樣的：
2、虛擬機是這樣的：
3、Dokcer是這樣的：
2、負載均衡器: LoadBalancer
負載均衡是高可用網絡基礎架構的的一個關鍵組成部分，有了負載均衡，我們通常可以將我們的應用服務器部署多臺，然後通過負載均衡將用戶的請求分發到不同的服務器用來提高網站、應用、數據庫或其他服務的性能以及可靠性。
負載平衡器模型通常分為兩類：第4層（傳輸層）和第7層（應用層）。
第4層（傳輸層）：：
- 根據網絡和傳輸層協議（IP，TCP，FTP，UDP）中的數據進行操作。
- 不認識http協議，對應其他TCP應用，例如基於C/S開發的ERP等系統。
第7層（傳輸層）：：
- 根據應用層協議（如HTTP）中的數據分發請求。
- 認識http協議，所以其應用範圍主要是眾多的網站或者內部信息平臺等基於B/S開發的系統。
負載均衡器主要分為硬件負載均衡和軟件負載均衡兩大類。
- 硬件負載均衡：對應第四層，如F5負載均衡器
- 軟件負載均衡：對應第七層，如 LVS、 Nginx和 HAproxy
兩種類型的負載平衡器都會收到請求，並根據配置的算法將這些請求分發到特定的服務器。一些行業標準算法是：
- 輪詢調度， Roundrobin，RR
- 加權輪詢， Weightedround robin，WRB
- 最少連接數， Leastconnections
- 最短的響應時間， Leastresponse time
在 Web應用程序中使用負載均衡器有兩個主要好處：
- 它通過確保單個 Web服務器不會被所有請求淹沒，來幫助維持一致的響應時間，因此處理每個請求的速度會相對慢些。
- 它保持高可用性。如果服務器崩潰，所有後續客戶端請求仍將成功，因為它們將路由到健康的服務器，並且用戶不會發現任何問題。
3、域名解析系統， DNS
當用戶在其地址欄中輸入 URL時，瀏覽器將獲取 URL的域部分（例如 www.google.com）並調用DNS 。DNS解析發回該網站服務器的IP地址位置（例如172.217.23.4）。一旦它具有IP地址，它就可以發送對網頁的實際請求。
- 如果你的Web應用程序使用負載均衡器，則應將域名配置為指向負載均衡器的域名或IP地址。
- 如果您沒有使用負載均衡器，那麼您可以將域名直接指向應用程序服務器的域名/ IP地址。
大多數互聯網域名註冊服務（例如 GoDaddy，萬網等）都提供DNS管理控制檯。這些允許你配置域名（和子域）以指向應用程序的位置。
如果你願意，還可以將您的域名服務器轉移到阿里雲、騰訊雲等雲提供商，並從那裡進行管理。這樣做的好處是可以將所有應用程序環境配置保存在一個位置，並使其更易於自動化。
4、HTTPS/SSL證書
如果你正在構建Web應用程序（或靜態網站），則需要通過HTTPS提供服務，以確保用戶與服務器之間的安全通信。現在使用 HTTPS 也有 SEO的好處，所以沒有理由不使用它。
這意味著需要在後端安裝SSL證書。具體來說，需要在任何服務器上安裝它們，這是客戶端請求的第一個聯繫點。這通常意味著負載均衡器和CDN服務器，但如果你沒有使用負載均衡器，也可能是應用程序服務器。
- 你可以使用 LetsEncrypt免費生成證書。
- 如果你使用的是雲基礎架構，則可以使用託管服務，例如 AWSCertificateManager。這允許你創建並自動續訂SSL證書並將其分發到應用程序服務器，負載平衡器和CDN服務器。
- 只有中大型的 HTTPS證書授權中心才會被瀏覽器承認，否則會顯示為不安全，需要手動信任。
目前SSL證書根據驗證級別分為三種類型
- 域名型SSL證書，簡稱DV SSL
- 企業型SSL證書，簡稱OV SSL
- 增強型SSL證書，簡稱EV SSL。
- 它們之間都有一定的區別，認證級別也都不同，各自適合不同規模類型的網站安裝。
一般情況下，企業類網站使用的OV SSL證書比較多，而且價格也適中，在大眾用戶可接受範圍內。
5、數據庫，Database
幾乎所有Web應用程序都需要在某處保留數據。在大多數情況下，某處即某種形式的數據庫。數據庫的主要工作是將數據可靠地保存到永久存儲器中，並允許通過查詢檢索數據。它還可以圍繞它存儲的數據結構強制執行一些規則約束。
5.1 數據庫的種類
早期比較流行的數據庫模型有三種，分別為層次式數據庫、網絡式數據庫和關係型數據庫。
而在當今的互聯網中，最常用的數據庫模型主要是兩種，即關係型（SQL）數據庫和非關係型（NoSQL）數據庫。
- 關係數據庫（例如 MySql，Postgres，SQLServer，Oracle，SQLite）已經存在了40多年，並且一直是大多數Web應用程序的支柱。
- 而在過去十年左右的時間裡，NoSQL數據庫（例如MongoDB，Cassandra，CouchDB，DynamoDB）在Web應用程序中變得越來越普遍，主要是因為它們具有可擴展性優勢和數據結構靈活性。
5.2 數據庫部署
你可以在一臺服務器上託管數據庫，但在生產方案中更常見的是將其託管在某種形式的集群2臺或更多服務器上。這可確保數據庫具有高可用性並降低數據丟失的風險，例如，如果一臺服務器的存儲損壞。
近年來，少數雲託管的“無服務器數據庫”已經可用。這些是可以通過API調用的數據庫，但你無需設置服務器來託管它們。除了處理諸如自動備份之類的事情之外，雲供應商還為您無形地執行此操作。這些示例包括 DynamoDB（NoSQL）， Firebase實時數據庫（ NoSQL）和 Aurora無服務器（關係）。
5.3 數據庫基礎方案
來源：架構設計之「數據庫從主備到主主的高可用方案」
無論底層是關係型數據庫，還是NoSQL數據庫，無論是 Mysql 還是 Redis、MongoDB，在架構設計上都是相通的。
數據庫服務器的基礎方案分為三種：
- 一主一備的架構（主備式）
- 一主一從的架構（主從式）
- 互為主從的架構（主主式）
1、一主一備的架構(主備式)
主備式架構是雙機部署中最簡單的一種架構，幾乎市面上所有的數據庫系統都會自帶這個主備功能。
其思路也特別的簡單：
- 將數據庫部署到兩臺機器，其中一臺機器(代號A)作為日常提供數據讀寫服務的機器，稱為「主機」。
- 另外一臺機器(代號B)並不提供線上服務，但會實時的將「主機」的數據同步過來，稱為「備機」。
- 一旦「主機」出了故障，通過人工的方式，手動的將「主機」踢下線，將「備機」改為「主機」來繼續提供服務。
這個架構的優缺點都很明顯，優點就是幾乎不需要做什麼開發改造，各類數據庫就支持這種模式，部署維護起來也簡單，並沒有引入額外的系統複雜度和瓶頸。
但是缺點呢，就是當「主機」出現故障的時候，需要人工去幹預啊，運維同學很辛苦的，而且處理還不一定及時。再還有一個缺點就是，主備架構會造成嚴重浪費資源，畢竟需要一臺與「主機」同等配置的「備機」長期備著，但又不作為線上服務來使用，你說浪費不浪費。
為了解決這個資源浪費問題，我們就得想一個把「備機」也用起來的方案：主從式架構。
2、一主一從的架構(主從式)
主從式架構大體上與上述的主備式架構差不多。區別就是主備式的「備機」平時是不幹活的的，主要起到備份的作用。而主從式的「備機」改為了「從機」，平時也要提供服務，跟「主機」一樣隨時隨刻的在幹活的。
- 主從式架構中的「從機」雖然也在隨時隨刻提供服務，但是它只提供「讀」服務，並不提供「寫」服務。
- 「主機」會實時的將線上數據同步到「從機」，以保證「從機」能夠正常的提供讀操作。
- 這種架構相比較主備式，對資源是一種節約，畢竟「從機」也在提供服務，沒有白白的浪費。並且在「主機」出現故障時，在人工介入之前，好歹「從機」也是能夠提供數據的「讀」操作的，畢竟大多數業務都是「讀」多「寫」少，因此對穩定性又提高了一個層次。
- 缺點就是架構稍微複雜了一點，畢竟「主機」和「從機」都有「讀」服務，那麼前端業務系統就需要用一定策略去判斷該路由到哪一臺去讀取數據。還有就是，延遲問題，「主機」的數據同步到「從機」難免會有一定程度的延遲，這個延遲可能會對數據實時性要求較高的業務有一定影響。
3、互為主從的架構(主主式)
互為主從的架構是指兩臺機器自己都是主機，並且也都是作為對方的從機。兩臺機器都提供完整的讀寫服務，因此無需切換，客戶機在調用的時候隨機挑選一臺即可，當其中一臺宕機了，另外一臺還可以繼續服務。
- 採用 互為主從架構 有個複雜點就是，因為兩臺主機都接受寫數據，那就需要將寫的最新數據實時的同步給對方，需要將數據進行兩臺主機的雙向複製。
- 而雙向複製不可避免的會在一定程度上帶來數據延遲、極端情況下甚至有數據丟失等問題。
- 在實際業務中，有些業務數據對一致性要求是非常高的，並不能接受數據的延遲、丟失，因此這類業務也不適合互為主從的模式，比如金融業務。
- 但是我們互聯網業務中大多數場景還是沒有這麼高要求的，所以這種模式對於一般場景還是用的蠻多。
至於數據庫集群方案，我暫時沒看懂，就不寫了。。。
6、Blob / 文件存儲
雖然數據庫通常用於存儲動態數據（例如，由最終用戶或API客戶端生成），但是存在某些類別的數據（ 非結構化數據），這些數據不能由用戶改變或者基於文件而不適合數據庫存儲，例如：
- 前端網站資源，如圖像， Javascript， CSS，字體，音頻，視頻文件。
- 用戶通過表單上傳的各類文件。
雲服務供應商不是將這些存儲在數據庫中，而是提供專用服務來存儲這些服務，例如 AWSSimpleStorageService（S3）， Azure， GoogleCloudStorage和阿里雲 OSS等。
這樣做的好處是雲供應商可以安全地存儲文件，並可以為其製作冗餘副本，以最大限度地降低數據丟失的風險。
6.1 關於 Blob 存儲:
Blob 存儲用於：
- 直接向瀏覽器提供圖像或文檔。
- 存儲文件以供分佈式訪問。
- 對視頻和音頻進行流式處理。
- 向日志文件進行寫入。
- 存儲用於備份和還原、災難恢復及存檔的數據。
- 存儲數據以供本地或 Azure 託管服務執行分析
7、內容分發網絡（CDN）
Blob /文件存儲服務允許客戶端通過 HTTP端點訪問文件。例如，您的Web應用程序的HTML標記可以簡單地鏈接到AWS S3中存儲的圖像和CSS文件的URL。傳統網絡訪問：
但是，假設我的用戶位於中國，我的S3存儲位於美國西部 - 數據傳輸距離數千英里，因此我的用戶會看到延遲。
CDN是什麼？使用CDN有什麼優勢？
- CDN是雲供應商提供的服務，它們在全球範圍內分佈有“邊緣服務器”。
- 這些邊緣服務器從“原點”（例如，blob /文件存儲位置）獲取文件的副本。你的前端Web應用程序將指向 其CDN URL，而不是指向靜態資產的Blob存儲URL。
- 現在，客戶端和“邊緣”之間的距離遠不是幾千英里的往返，而是更少，因此文件的獲取速度更快。
使用了CDN的網站訪問：
7.1 CDN工作流
通過權威DNS服務器來實現最優節點的選擇，通過緩存來減少源站的壓力。
8、緩存服務：CachingService
雖然 CDN是靜態文件的一種緩存形式，但 Web應用程序可能需要臨時緩存動態數據。
例如，假設存在一個數據庫查詢，該查詢對昨天的數據執行計算，其結果每天經常被成千上萬的用戶訪問。每次用戶請求此數據時聯繫數據庫就沒有任何意義。
對此的解決方案是使用高速緩存服務在第一個用戶請求之後將結果存儲一段時間。通過緩存將更快地提供對該數據的後續請求。
緩存服務本質上是一種特殊類型的數據庫。 緩存採用鍵值存儲的形式，其中鍵是應用程序代碼用於查詢數據的字符串（例如DailySiteStats_2018-10-17），值是緩存的實際數據。緩存的數據通常完全保存在內存中，這使得從緩存中檢索數據的速度非常快。
常見的緩存服務是 Redis和 Memcached。AWS通過其 Elasticache服務提供這兩者的託管版本。
8.1 Redis和 Memcached對比
Redis和 Memcached是都是主流的開源內存數據存儲。雖然它們既易於使用又提供高性能，但在選擇引擎時需要考慮重要的差異。Memcached是為簡單而設計的，而 Redis提供了豐富的功能，使其能夠廣泛用於各種用例。
MemcachedRedis亞毫秒級延遲是是開發人員易用性是是數據分區是是多語言支持是是高級數據結構-是多線程架構是-快照-是複製-是發佈/訂閱-是Lua腳本-是地理空間支持-是
亞毫秒級延遲:
Redis和 Memcached都支持亞毫秒的響應時間。通過將數據存儲在內存中，它們可以比基於磁盤的數據庫更快地讀取數據。
開發人員易用性:
Redis和 Memcached在語法上都很容易使用，並且需要最少量的代碼才能集成到您的應用程序中。
數據分區:
Redis和Memcached`都允許您在多個節點之間分發數據。這允許您在需求增長時向外擴展以更好地處理更多數據。
支持廣泛的編程語言:
Redis和 Memcached都有許多面向開發人員的開源客戶端。支持的語言包括 Java，Python，PHP，C，C++，C＃，JavaScript，Node.js，Ruby，Go等等。
高級數據結構:
除了字符串， Redis還支持列表，集合，有序集，哈希，位數組等。應用程序可以使用這些更高級的數據結構來支持各種用例。例如，你可以使用Redis排序集輕鬆實現遊戲排行榜，該排行榜保持按其排名排序的玩家列表。
多線程架構：
由於 Memcached是多線程的，因此它可以使用多個處理核心。這意味著您可以通過擴展計算容量來處理更多操作。
快照:
使用 Redis，您可以使用即時快照將數據保存在磁盤上，該快照可用於存檔或恢復。
複製:
Redis允許您創建 Redis主數據庫的多個副本。這允許您擴展數據庫讀取並具有高可用性集群。
發佈/訂閱:
Redis支持使用模式匹配的 Pub/Sub消息傳遞，您可以將其用於高性能聊天室，實時評論流，社交媒體源和服務器互通。
Lua腳本:
Redis允許您執行事務性 Lua腳本。腳本可以幫助您提高性能並簡化應用程序。
地理空間支持:
Redis具有專門用於大規模處理實時地理空間數據的命令。您可以執行諸如查找兩個元素（例如人或地點）之間的距離以及查找點的給定距離內的所有元素之類的操作。
9、消息隊列：Message queue
適用於批處理任務和分離應用程序的異步消息收發
有時，你程序需要執行的任務與響應用戶請求沒有直接關係。
例如，假設用戶上傳了需要編碼和水印的視頻。但這是一項長期運行的任務，因此讓用戶在完成時等待是沒有意義的。更好的方法是異步執行此操作。您的網絡應用程序代碼會在隊列中創建一條作業消息，並通知您的用戶，當水印視頻準備就緒時，他們將收到一封電子郵件（消息）。
然後，你將擁有一個可以執行以下操作的工作任務流：
- 從隊列中讀取消息。
- 開始處理視頻。
- 完成後，保存視頻的編碼副本。
- 向用戶發送通知電子郵件（消息）。
- 從隊列中刪除消息。
這裡有2個架構組件：
您可以通過以下幾種方式實現 worker任務：
- 調度 CRON作業以觸發應用程序服務器上安裝的指定代碼，以便按特定計劃從隊列中讀取。
- 將消息添加到隊列時，使用 FaaS平臺調用工作器代碼。
9.1 Message queue 簡介
消息隊列是一種異步的服務間通信方式，適用於無服務器和微服務架構。消息在被處理和刪除之前一直存儲在隊列上。每條消息僅可被一位用戶處理一次。消息隊列可被用於分離重量級處理、緩衝或批處理工作以及緩解高峰期工作負載。
現在常用的MQ組件有 activeMQ、 rabbitMQ、 rocketMQ、 zeroMQ 還有近年來火熱的 kafka,從某些場景來說也是MQ，當然kafka的功能更加強大，雖然不同的MQ都有自己的特點和優勢，但是，不管是哪種MQ，都有MQ本身自帶的一些特點。
9.2 MQ主要特性
特性說明推送或拉取傳送拉取是指不斷查詢隊列以獲取新消息。推送是指系統在有可用消息時通知用戶 (也稱為發佈/訂閱消息收發)。您還可以使用長輪詢讓拉取等待指定的時間，以便新消息在完成之前到達。定時或延遲傳送支持為消息設置特定的傳送時間。如果需要為所有消息設置相同延遲，可以設置一個延遲隊列。至少一次傳送消息隊列可以存儲多個消息副本以實現冗餘和高可用性，並在發生通信故障或錯誤的情況下重新發送消息，以確保它們至少經過一次傳送。確切一次傳送在不容許重複的情況下，FIFO (先進先出) 消息隊列會通過自動篩選重複來確保每個消息均精確地傳輸了一次 (且只有一次)。FIFO (先進先出) 隊列在這些隊列中，首先接受處理的是最早的 (或第一個) 條目，有時稱為“隊首”。消息優先級通常情況下，您可以為消息分配優先級，以確定要在隊列中添加該消息的位置，從而確保優先級較高的消息位於隊列前端並得到優先處理。
9.3 MQ應用示例
來源：MQ(消息隊列)常見的應用場景解析
我們的實際場景大概是一個基於微服務架構的電商系統，分為用戶微服務、商品微服務、訂單微服務、促銷微服務等。
基於微服務模式開發的系統，MQ的使用場景更多。這裡我們就列舉一下常見的應用示例。
1、註冊後的初始化
註冊後我們可能需要做很多初始化的操作，如：
- 調用郵件服務器發送郵件、調用促銷服務贈送優惠劵、下發用戶數據到客戶關係系統等。
- 那麼這時候我們將這些操作去監聽MQ，當用戶註冊成功過後，通過MQ通知其他業務進行操作。確保註冊用戶的性能。
2、後臺發佈商品
後臺發佈商品的時候:
- 商品數據需要從數據庫中轉換成搜索引擎數據（基於 elasticsearch）
- 那麼我們應該將商品寫入數據庫後，再寫入到 MQ，然後通過監聽 MQ來生成 elasticsearch對應的數據。
3、支付超時取消
用戶下單後，24小時未支付，需要取消訂單。
- 以前我們可能是定時任務循環查詢，然後取消訂單。
- 實際上，我更推薦類似延遲MQ的方式，避免了很多無效的數據庫查詢，將一個MQ設置為24小時後才讓消費者消費掉，這樣很大程度上能減輕服務器壓力。
4、支付完成後通知
- 支付完成後，需要及時的通知子系統（進銷存系統發貨，用戶服務積分，發送短信）進行下一步操作。
- 但是，支付回調我們都是需要保證高性能的，所以，應該直接修改數據庫狀態，存入MQ，讓MQ通知子系統做其他非實時的業務操作。這樣能保證核心業務的高效及時。
閱讀更多 真致信息技術 的文章
