本人才疏學淺，以下內容是個人檢視各種文章以及搜尋資料所寫出來的，所以如以下內容有不合適的地方，請及時糾正我，不吝賜教，本人在這不勝感激
前言
沒有總結過這塊的知識，因為平時這塊也是接觸不是很深，所以基本就是用的時候在去搜查詢資料，時間一長一些東西也就記不住了，在此將一些以前學過的以及現在在補充學習的內容寫出來，也是為了翻一下自己的舊賬，以及去思考自己下一步去做什麼。
在此也要提前說明，以下出現的參考文章沒有任何打廣告的嫌疑，只不過是自己當時看的文章。
一、中介軟體
1.中介軟體是什麼？
維基百科
中介軟體是一種計算機軟體，它為軟體應用程式提供超出作業系統可用服務的服務。可謂“軟體膠水”。[1]
中介軟體使軟體開發人員更容易實現通訊和輸入/輸出，因此他們可以專注於其應用程式的特定目的。儘管該術語自 1968 年以來一直在使用，但它在 1980 年代作為解決如何將較新的應用程式連結到較舊的遺留系統的問題的解決方案而廣受歡迎
該術語最常用於支援分散式應用程式中資料通訊和管理的軟體。2000 年的IETF研討會將中介軟體定義為“在傳輸（即通過 TCP/IP）層服務集之上但在應用程式環境之下的那些服務”（即在應用程式級API之下）。[3]在這個更具體的意義上，中介軟體_可以被描述為client-server 中的破折號（“-”），或者-to-_ in peer-to-peer。中介軟體包括網路伺服器、應用伺服器、內容管理系統。，以及支援應用程式開發和交付的類似工具
ObjectWeb 將中介軟體定義為：“位於網路中分散式計算系統兩側的作業系統和應用程式之間的軟體層。” [5]可被視為中介軟體的服務包括企業應用程式整合、資料整合、面向訊息的中介軟體(MOM)、物件請求代理(ORB) 和企業服務匯流排(ESB)
中介軟體也指將兩個或多個 API 分開並提供限速、身份驗證和日誌記錄等服務的軟體
廣義和狹義
- 廣義的說，所有不直接給客戶直接提供業務價值的軟體，都是中介軟體。舉例說明，nginx和WebSphere App Server、MySQL都是中介軟體，而一個營銷系統或者CRM系統、小額信貸系統，則不是中介軟體。
狹義上說，處於基礎設施層的軟體與業務系統軟體中間這一層的一些軟體或者庫、框架，我們叫中介軟體，不一定是獨立的程式。這樣就把上面提到的類似DB和Web Server之類的軟體劃分到基礎設施層了。狹義的中介軟體比如快取中介軟體、資料庫中介軟體、訊息中介軟體、服務化中介軟體、交易中介軟體、排程中介軟體、整合中介軟體等等。現在網際網路上說的一般是這幾個
引自 [[https://zhuanlan.zhihu.com/p/97625832](https://zhuanlan.zhihu.com/p/97625832)]
2.解決了什麼問題？
中介軟體它遮蔽了底層作業系統的複雜性，這樣可以使程式設計師面對一個簡單而統一的開發環境，減少程式設計的複雜性，專注於業務邏輯的開發，從而不必再為程式在不同系統軟體上的移植而重複工作，大大減少了技術上的負擔；而且提升了系統的穩定性，將一些風險轉移到中介軟體上。
中介軟體解決的問題其實也挺多的，主要是現在個人認知不到位，所以如果想深入瞭解的其實可以自行查閱資料。
二、訊息佇列
1.什麼是訊息佇列？
訊息佇列（Message Queue，簡稱MQ），指儲存訊息的一個容器，本質是個佇列。
訊息（Message）它是指在應用之間傳送的資料，訊息可以非常簡單，比如只包含文字字串，也可以更復雜，可能包含嵌入物件。
訊息佇列（Message Queue）是一種應用間的通訊方式，訊息傳送後可以立即返回，有訊息系統來確保資訊的可靠專遞，訊息釋出者只管把訊息釋出到MQ中而不管誰來取，訊息使用者只管從MQ中取訊息而不管誰釋出的，這樣釋出者和使用者都不用知道對方的存在
2.為什麼要有訊息佇列？
MQ(Message Queue)訊息佇列，是一種跨程式的通訊機制，用於上下游傳遞資訊；作為一個佇列，其主要的功能就是排隊積壓。面對高併發任務時，由於來不及同步處理，請求往往會發生堵塞，表現最為明顯的就是對資料庫的操作，如大量的insert、update之類的請求同時到達資料庫，直接導致無數的行鎖表鎖，甚至最後請求會堆積過多，從而觸發too many connections錯誤。
此外，當上遊服務處理能力遠大於下游的情況時，若上游服務直接呼叫下游服務，由於下游服務處理能力遠跟不上上游服務，因此明顯的後果就是下游服務因處理壓力而導致崩潰.
因此，MQ提出之初就是為了削峰限流，通過非同步處理請求，減少請求相應時間和邏輯及物理上的解耦，從而緩解系統的壓力，輕鬆應對高併發的情況
上游和下游
Definition 1: The direction of action
Upstream: receiving requests from.
Myupstreamservice is calling me.
Downstream: making requests to.
I am calling my downstream service
定義1:動作方向
上游:接收來自。我的上游業務在召喚我。
下游:向……提出請求。我要呼叫下游服務
Definition 2: The direction of dependency
Upstream: making requests to (and receiving responses from).
I am calling myupstreamservice.
Downstream: receiving requests from (and sending responses to).
My downstream service is calling me.
定義2:依賴的方向
上游:向上遊發出請求(並從上游接收響應)。我在呼叫上游業務。
下游:接收請求(並向請求傳送響應)。我的下游服務呼叫我。
So,
There are resources on the internet which support both of these definitions. Maybe we will resolve this question one day, but for now the answer is: it's either.
所以，網際網路上有支援這兩種定義的資源。也許有一天我們會解決這個問題，但目前的答案是:兩者皆有
引自——What is Upstream and Downstream services in a Micro-service based architecture?
3.談一下訊息佇列？
訊息佇列的話，因為傳統應⽤是從⼀個應⽤程式傳送訊息直接到另⼀個應⽤程式，但是如果傳送⼤量訊息的話，⽽且當⼀臺服務機已經掛掉時，另⼀臺的上的程式功能就⽆法實現，也就是出現了服務異常，這樣對⽤戶的體驗感是⽐較差的，所以在兩者中間加⼀個訊息佇列，也就是其實說的就和兵來將擋⽔來⼟掩這句話⼀樣，為的是當⼀⽅服務掛掉時，另⼀⽅服務還可以正常運⾏；但此時就需要考慮訊息佇列中的問題，⽐如就是當訊息佇列服務掛掉怎麼辦，還有是否重複訊息，訊息是否正確處理等問題；通過訊息佇列就可以降低系統耦合性。
⽽Rabbit和阿⾥的Rocket還有Apache的Kafka、Active都是為了實現訊息機制，⽽Rabbit的話是萬級的吞吐量，Kafka是百萬級的；⽽且Rabbit的效能較⾼，⼀般⽤於主從架構中，⽽Kafka天⽣分散式，效能也⽐較好，⼀般⽤於⼤資料領域，⽐較依賴zookeeper。
Rabbit⼯作模式的話，有簡單、⼯作、釋出訂閱、路由、主題五種，⽽其中簡單和⼯作模式基本是模擬了⽣產者消費者的問題，釋出和訂閱為了滿⾜資源共享即訊息的共享，每個消費者都有⾃⼰的訊息佇列，⽽每個訊息佇列都得去繫結交換機，訊息通過交換機再通過佇列再到消費者。路由模式是為了消費者可以有選擇的去消費訊息，主題模式的話，類似正規表示式給交換機新增匹配機制，匹配到相應佇列，然後佇列中的監聽消費者接收訊息進⾏消費。什麼要⽤它，是因為在分散式結構中，模組和模組之間需要相互協同，所以選擇了非同步並且多執行緒Rabbit，這樣可以使處理資料變得⾼校和穩定以及主要的解耦提升⽹站效能。為什麼⽤它，是因為其他MQ的開源社群都沒有個開源社群⽕，⽽且這個教程⽐較全，所以選擇了這個。Kafka其實⼀種分散式流式系統，側重點不⼀樣，rabbit更適合⼀些項⽬的開發吧。
當然這只是我看到的一些內容，因為個人也是沒有接觸過這類專案的開發，沒有體驗過。
如果還需要認識，可以參考以下文章（並無任何打廣告的意圖，全是網上搜的看的資料）
************************************************************************************************
面試連環炮系列（五）：你們的專案為什麼要用RabbitMQ
別糾結了，教你如何做 ------訊息中介軟體選型分析
為什麼使用Kafka、ActiveMQ、RabbitMQ、RocketMQ 訊息佇列？
************************************************************************************************
三、ElasticSearch技術
1.全文搜尋、倒排索引？
通常，在“精度”和“召回”之間存在權衡。 高精度意味著呈現較少的不相關結果（無誤報），而高召回率意味著丟失較少的相關結果（無誤報）。 使用 LIKE 運算子可以為您提供 100% 的精確度，而不會在召回方面做出讓步。 全文搜尋工具為您提供了很大的靈活性來調低精度以獲得更好的召回率。
大多數全文搜尋實現使用“倒排索引”。 這是一個索引，其中鍵是單個術語，關聯的值是包含該術語的記錄集。 全文搜尋被優化以計算這些記錄集的交集、並集等，並且通常提供排名演算法來量化給定記錄與搜尋關鍵字匹配的強度。
SQL LIKE 運算子可能非常低效。 如果將其應用於未編入索引的列，則將使用完整掃描來查詢匹配項（就像對未編入索引的欄位的任何查詢一樣）。 如果該列已編入索引，則可以針對索引鍵執行匹配，但效率遠低於大多數索引查詢。 在最壞的情況下，LIKE 模式將具有需要檢查每個索引鍵的前導萬用字元。 相比之下，許多資訊檢索系統可以通過在選定欄位中預編譯字尾樹來支援前導萬用字元。
全文搜尋的其他典型特徵是
詞法分析或標記化——將非結構化文字塊分解為單獨的單詞、短語和特殊標記
形態分析或詞幹提取——將給定詞的變體合併為一個索引詞； 例如，將“小鼠”和“滑鼠”，或“電氣化”和“電動”視為同一個詞
排名——測量匹配記錄與查詢字串的相似度
可以通過這篇博文認識一下：什麼是倒排索引？
2.ElasticSearch技術？
Lucene
Apache Lucene是一個免費的開源搜尋引擎軟體庫，最初由Doug Cutting完全用Java編寫。它由Apache 軟體基金會支援，並根據Apache 軟體許可證釋出。Lucene 被廣泛使用，是非研究搜尋應用程式的標準基礎
Lucene可以看作一個jar包，它封裝好了一些複雜的API以及包含了倒排索引，資料儲存到磁碟。
也就是說lucene是一種採取了倒排索引的方式進行高效率搜尋的框架。但是它api複雜，且不支援叢集。
引入 lucene 依賴，基於它的 api 進行開發就行了，用了 lucene，我們就可以基於已有的資料建立倒排索引。而Elasticsearch完美解決了lucene的這些缺點，它天然支援叢集，api相對簡單，開箱即用。底層還是封裝的lucene。
ES本身底層是基於搜尋引擎去做的，所以更擅⻓去做⼀些全⽂匹配，複雜的⼀些搜尋或索引，因為
它⾥⾯是有倒排索引的⼀些機制，分詞能⼒⽐較強，但是它對寫⼊和寫出的⽀持不是很好；⽽
MongoDB的話，雖然是⼀種⽂檔型的資料庫，但底層資料結構還是B樹實現的，⽽且⽀持事務，打算是
替換mysql，所以兩者定位也不同。
維基百科
Elasticsearch 是一個基於** Lucene** 庫的搜尋引擎。 它提供了一個分散式的、支援多租戶的全文搜尋引擎，帶有一個 HTTP Web 介面和無模式的 JSON 文件。 Elasticsearch 是用 Java 開發的，在原始碼可用的伺服器端公共許可證和彈性許可證下獲得雙重許可，[3] 而其他部分 [4] 屬於專有（原始碼可用）彈性許可證。 官方客戶端支援 Java、.NET (C#)、PHP、Python、Apache Groovy、Ruby 和許多其他語言。 [5] 根據 DB-Engines 排名，Elasticsearch 是最受歡迎的企業搜尋引擎
Elasticsearch 可用於搜尋各種文件。 它提供可擴充套件的搜尋，具有近乎實時的搜尋，並支援多租戶。 [5] “Elasticsearch 是分散式的，這意味著索引可以分為多個分片，每個分片可以有零個或多個副本。每個節點託管一個或多個分片，並充當協調器，將操作委託給正確的分片。重新平衡和 路由是自動完成的”。[5] 相關資料通常儲存在同一個索引中，該索引由一個或多個主分片和零個或多個副本分片組成。 一旦建立了索引，就不能更改主分片的數量。 [25]
Elasticsearch 與名為 Logstash 的資料收集和日誌解析引擎、名為 Kibana 的分析和視覺化平臺以及輕量級資料傳送器的集合 Beats 一起開發。 這四種產品旨在用作整合解決方案，稱為“Elastic Stack”（以前稱為“ELK stack”）。[26]
Elasticsearch 使用 Lucene 並嘗試通過 JSON 和 Java API 使其所有功能可用。 它支援分面和滲透，[27] [28] 這對於通知新文件是否與註冊查詢匹配很有用。 另一個功能稱為“閘道器”，處理索引的長期永續性；[29] 例如，可以在伺服器崩潰時從閘道器恢復索引。 Elasticsearch 支援實時 GET 請求，這使得它適合作為 NoSQL 資料儲存，[30] 但它缺乏分散式事務
看張圖——來自B站UP主“不高興就喝水”
3.關於ElasticSearch的一些問題
ElasticSearch, Sphinx, Lucene, Solr, Xapian。哪種適合哪種用途
作為 ElasticSearch 的建立者，也許我可以給你一些關於我為什麼繼續並首先建立它的推理:)。
使用純 Lucene 具有挑戰性。 如果您希望它真正執行良好，您需要注意很多事情，而且，它是一個庫，因此沒有分散式支援，它只是一個您需要維護的嵌入式 Java 庫。
就 Lucene 的可用性而言，早在（現在將近 6 年），我建立了 Compass。 它的目標是簡化 Lucene 的使用並使日常 Lucene 更簡單。 我一次又一次遇到的是能夠分發 Compass 的要求。 我開始在 Compass 內部進行研究，通過與 GigaSpaces、Coherence 和 Terracotta 等資料網格解決方案整合，但這還不夠。
就其核心而言，需要對分散式 Lucene 解決方案進行分片。 此外，隨著 HTTP 和 JSON 作為無處不在的 API 的進步，這意味著可以輕鬆使用具有不同語言的許多不同系統的解決方案。
這就是我繼續建立 ElasticSearch 的原因。 它具有非常先進的分散式模型，原生支援 JSON，並公開了許多高階搜尋功能，所有這些功能都通過 JSON DSL 無縫表達。
Solr 也是一個通過 HTTP 公開索引/搜尋伺服器的解決方案，但我認為 ElasticSearch 提供了一個非常優越的分散式模型和易用性（儘管目前缺乏一些搜尋功能，但不會太久，並且在任何 在這種情況下，計劃是將所有 Compass 功能放入 ElasticSearch 中）。 當然，我是有偏見的，因為我建立了 ElasticSearch，所以你可能需要自己檢查。
至於Sphinx，我沒用過，不便評論。 我可以向您推薦的是 Sphinx 論壇上的這個帖子，我認為它證明了 ElasticSearch 的卓越分散式模型。
當然，ElasticSearch 的功能遠不止分散式。 它實際上是在考慮到雲的情況下構建的。 您可以檢視網站上的功能列表
為什麼要使用 NoSQL（MongoDB、Cassandra、CouchDB 等）而不是 Lucene（或 Solr）作為“資料庫”
我（我相信其他人）在答案中尋找的是對它們的一些深入比較。 讓我們一起跳過關聯式資料庫的討論，因為它們用於不同的目的。
Lucene 提供了一些重要的優勢，例如強大的搜尋和權重系統。 更不用說 Solr 中的方面（Solr 很快就會被整合到 Lucene 中，是的！）。 您可以使用 Lucene 文件來儲存 ID，並像 MongoDB 一樣訪問這些文件。 將它與 Solr 混合使用，您現在可以獲得基於 WebService 的負載平衡解決方案。
在談論 MongoDB 的類似資料儲存和可擴充套件性時，您甚至可以比較 Velocity 或 MemCached 等程式外快取提供程式。
MongoDB 的限制讓我想起了使用 MemCached，但我可以使用 Microsoft 的 Velocity，並且比 MongoDB 擁有更多的分組和列表收集能力（我認為）。 沒有比在記憶體中快取資料更快或可擴充套件的了。 甚至 Lucene 也有記憶體提供者。
MongoDB（和其他）確實有一些優勢，例如其 API 的易用性。 新建一個文件，建立一個 id 並儲存它。 完畢。 好，容易.
Solr 與 ElasticSearch
回答一：
更新
既然問題範圍已經更正，我也可以在這方面新增一些內容：
Apache Solr和ElasticSearch之間有很多比較可用，因此我將參考我自己認為最有用的那些，即涵蓋最重要的方面：
- Bob Yoplait 已經將 kimchy 的答案與ElasticSearch、Sphinx、Lucene、Solr、Xapian 聯絡起來。哪個適合哪個用途？，總結了他_繼續建立 ElasticSearch_的原因，在他看來，與 Solr 相比，ElasticSearch提供了更優越的分散式模型和易用性。
- Ryan Sonnek 的實時搜尋：Solr 與 Elasticsearch提供了一個有見地的分析/比較，並解釋了為什麼他從 Solr 切換到 ElasticSeach，儘管他已經是一個快樂的 Solr 使用者 - 他總結如下：在構建標準搜尋應用程式時，Solr可能是首選武器，但Elasticsearch將其提升到一個新的水平，其架構用於建立現代實時搜尋應用程式。Percolation 是一項令人興奮的創新功能，可單槍匹馬地將 Solr 吹出水面。Elasticsearch 具有可擴充套件性、快速性，並且是與.Adios Solr，很高興認識你。[強調我的]
- 維基百科上關於 ElasticSearch 的文章引用了著名的德國 iX 雜誌的比較，列出了優點和缺點，這幾乎總結了上面已經說過的內容：優點：缺點：
- ElasticSearch 是分散式的。不需要單獨的專案。副本也接近實時，這被稱為“推送複製”。
- ElasticSearch 完全支援 Apache Lucene 的近實時搜尋。
- 處理多租戶不是一種特殊的配置，使用 Solr 需要更高階的設定。
- ElasticSearch 引入了閘道器的概念，使完整備份更容易。
- 只有一個主要開發人員_[根據當前的_Elasticsearch GitHub 組織不再適用，除了首先擁有非常活躍的提交者基礎之外]
- 沒有自動預熱功能 [根據新的索引預熱 API不再適用]
初步答覆
它們是針對完全不同用例的完全不同的技術，因此根本無法以任何有意義的方式進行比較：
- Apache Solr - Apache Solr 在易於使用、快速的搜尋伺服器中提供 Lucene 的功能，並具有分面、可擴充套件性等附加功能
- Amazon ElastiCache - Amazon ElastiCache 是一項 Web 服務，可讓您輕鬆在雲中部署、操作和擴充套件記憶體快取。
[強調我的]
也許這已經以某種方式與以下兩種相關技術混淆了：
- ElasticSearch -它是一個基於 Apache Lucene 構建的開源 (Apache 2)、分散式、RESTful、搜尋引擎。
- Amazon CloudSearch - Amazon CloudSearch 是一項完全託管的雲端搜尋服務，讓客戶能夠輕鬆地將快速且高度可擴充套件的搜尋功能整合到他們的應用程式中。
該_Solr的_和_ElasticSearch_產品聽起來一見鍾情驚人地相似，都使用同樣的後端搜尋引擎，即Apache的Lucene的。
雖然_Solr_較舊、用途廣泛且成熟並相應地被廣泛使用，但_ElasticSearch_已專門開發用於解決_Solr_在現代雲環境中具有可擴充套件性要求的缺點，這些缺點很難（呃）用_Solr 解決_。
因此，將_ElasticSearch_與最近推出的_Amazon CloudSearch_進行比較可能是最有用的（請參閱介紹性文章開始以低於 100 美元/月的價格進行一小時搜尋），因為兩者都聲稱原則上涵蓋了相同的用例.
回答二：
我看到上面的一些答案現在有點過時了。從我的角度來看，我每天都使用 Solr（雲和非雲）和 ElasticSearch，這裡有一些有趣的區別：
- 社群：Solr 擁有更大、更成熟的使用者、開發者和貢獻者社群。ES 擁有較小但活躍的使用者社群和不斷增長的貢獻者社群
- 成熟度：Solr 更成熟，但 ES 增長很快，我認為它很穩定
- 效能：難以判斷。我/我們沒有做過直接的效能基準測試。LinkedIn 的一個人曾經比較過 Solr、ES 和 Sensei，但最初的結果應該被忽略，因為他們對 Solr 和 ES 都使用了非專家設定。
- 設計：人們喜歡 Solr。Java API 有點冗長，但人們喜歡它的組合方式。不幸的是，Solr 程式碼並不總是很漂亮。此外，ES 內建了分片、實時複製、文件和路由。雖然其中一些也存在於 Solr 中，但感覺有點像事後的想法。
- 支援：有些公司為 Solr 和 ElasticSearch 提供技術和諮詢支援。我認為唯一為兩者提供支援的公司是 Sematext（披露：我是 Sematext 創始人）
- 可擴充套件性：兩者都可以擴充套件到非常大的叢集。ES 比 Solr 之前的 Solr 4.0 版本更容易擴充套件，但在 Solr 4.0 中則不再如此。
如需更全面地瞭解 Solr 與 ElasticSearch 主題，請檢視https://sematext.com/blog/solr-vs-elasticsearch-part-1-overview/。這是 Sematext 對 Solr 與 ElasticSearch 進行直接和中立比較的系列文章中的第一篇文章。披露：我在 Sematext 工作
可以參考以下博文
《Elasticsearch 快速開始》《老婆問我ES是誰？》《用最簡單的話告訴你什麼是ElasticSearch》
四、分散式與微服務
1.什麼是分散式與微服務？
分散式的話，其實也去查過以及去看過⽹上的⼀些解釋，然後分散式它其實也並不是某⼀⻔具體的
技術，也不是什麼具體的框架，簡單的理解就是它是通過計算能⼒和資料儲存能⼒分佈到不同的伺服器
上，也就可以理解為解決⼀種問題的⽅案吧，⽽這個微服務的話就是在垂直⽅向上做了⼀個細拆分，將
服務不斷的細化，這樣可以提⾼系統的可⽤性和容錯⼒、併發性等等，相關實現技術的話現在⽐較流⾏
的Springcloud和重阿⾥重啟的DubboRPC框架（RPC是遠端過程調⽤，是定義的⼀種計算機通訊協議
即規則，即它實現了⼀臺計算機上的程式可以調⽤另⼀個計算機上的程式，也就是實現了兩個實體地址
之間的通訊）+zookeeper實現微服務⽅案。既然⼀個系統是微服務架構的話，那它也是⼀個分散式系
統。
維基百科
分散式計算是研究分散式系統的電腦科學領域。 分散式系統是一種系統，其元件位於不同的聯網計算機上，它們通過從任何系統向彼此傳遞訊息來通訊和協調它們的動作。 元件彼此互動以實現共同目標。 分散式系統的三個顯著特徵是：元件的併發性、缺少全域性時鐘和元件的獨立故障。 分散式系統的示例多種多樣，從基於SOA 的系統到大型多人線上遊戲，再到點對點應用程式。在分散式系統中執行的計算機程式稱為分散式程式（分散式程式設計就是編寫此類程式的過程）。 訊息傳遞機制有許多不同型別的實現，包括純 HTTP、類似 RPC 的聯結器和訊息佇列。分散式計算也指使用分散式系統來解決計算問題。 在分散式計算中，一個問題被分成許多工，每個任務由一臺或多臺計算機解決，它們通過訊息傳遞相互通訊
可參考博文：《三分鐘讀懂TT貓分散式、微服務和叢集之路》《「和耳朵」聊聊微服務與分散式系統》
《什麼是分散式系統，如何學習分散式系統》
五、Docker技術
維基百科
Docker 可以將應用程式及其依賴項打包到可以在任何 Linux、Windows 或 macOS 計算機上執行的虛擬容器中。這使應用程式能夠在各種位置執行，例如本地、公共雲和/或私有云。[11]在 Linux 上執行時，Docker 使用Linux 核心的資源隔離功能（例如cgroups和核心名稱空間）和具有聯合功能的檔案系統（例如OverlayFS）[12]允許容器在單個 Linux 中執行例如，避免啟動和維護的開銷虛擬機器。[13]macOS 上的Docker使用 Linux虛擬機器來執行容器。[14]
由於 Docker 容器是輕量級的，單個伺服器或虛擬機器可以同時執行多個容器。[15] 2018 年的一項分析發現，典型的 Docker 用例涉及每臺主機執行 8 個容器，而四分之一的分析組織在每臺主機上執行 18 個或更多。[16]
Linux 核心對名稱空間的支援主要[17]隔離了應用程式對操作環境的看法，包括程式樹、網路、使用者 ID 和掛載的檔案系統，而核心的 cgroup 為記憶體和 CPU 提供資源限制。[18]從 0.9 版本開始，除了通過libvirt、LXC和systemd-nspawn使用抽象的虛擬化介面外，Docker 還包含自己的元件（稱為“ libcontainer ”）以使用 Linux 核心直接提供的虛擬化工具。[19][10][11][20]
Docker 實現了一個高階API來提供隔離執行程式的輕量級容器。[21] Docker 容器是標準程式，可以使用核心特性來監控它們的執行，包括。使用 strace 來觀察和調解系統呼叫。
可參考文章：《Docker 容器入門》、《兩小時入門Docker》、《Java後端學習路線》
六、阿里雲第三方技術
這塊其實也是簡單的進行應用，並沒有深入的去了解。2020年的疫情那段期間因為阿里雲有活動所以就搞了一臺2G的伺服器，系統是centos7，也執行不了太多東西。當時主要就用了一下物件儲存OSS、視訊點播、簡訊服務，要注意的是簡訊服務好像是在2020年12月份不允許隨便申請了，也就是如果沒有一些重要認證的話基本不會給你用。
物件儲存和視訊點播這些第三方功能，阿里雲是直接有API文件可以看的，而且比較全面。
阿里雲開源映象站：https://developer.aliyun.com/mirror/
儲存產品文件：https://www.aliyun.com/help/docs/storage?spm=5176.12672711.help.40.4e661fa3JVBpDX
幫助文件：https://help.aliyun.com/?spm=5176.7991389.J_9220772140.6.11d347ealWa1tH
（雖然在網上看到阿里風評不是很好，而且再加上最近鬧得這事，但一碼歸一碼，技術這塊是真的做的很不錯的）
七、JWT
jwt它也是json的⼀套標準吧，可以通過宣告資訊去獲取伺服器資源，可被加密，去做認證等；項⽬
中主要是做⼀個認證，因為傳統的通過redis實現的集中式session管理（因為session中的資料類似map
結構，⽽redis也⽀持hash資料型別，所以⽤redis⽐較好），也是基於http協議，⽽這個協議是⽆狀態
的，所以每次當有⽤戶進⾏認證的時候，⼀般就需要在記憶體中產⽣新的session，⽽如果⽤戶增多，是對
伺服器這塊有壓⼒，⽽且不利於分散式應⽤的開發，因為認證資訊保留在記憶體中的話，下⼀次認證就還
需要去這臺伺服器。⽽且因為是基於cookie進⾏識別，所以就會產⽣csrf跨站請求攻擊，這是不好的；
⽽token雖然也是基於http協議，但不需要在服務端保留⽤戶的認證資訊或會話資訊，基本流程的話就
是，⽤戶輸⼊⽤戶名和密碼請求伺服器，伺服器進⾏驗證⽤戶資訊，然後通過驗證後給⽤戶發⼀個
token，然後客戶端儲存這個token，然後每次傳送請求的時候都會帶上token，服務端再驗證token並返
回資料，要把token放請求頭中，伺服器這邊要⽀持跨域請求cors，具體⽅式的話可以在java中新增跨
域註解或者採⽤⽹關的⽅式去實現；jwt主要有頭部資訊、有效資訊、簽證資訊這三個部分。
參考文章：《傻傻分不清之 Cookie、Session、Token、JWT》、《認識JWT》、《基於jwt的token驗證》
最後
今天是8月15日，偉大的中華人民共和國經歷14年的時間打敗了日本帝國主義侵略者，76年前的今天也就是1945年8月15日正午，日本無條件投降，日本裕仁天皇向全日本廣播，接受波茨坦公告、實行無條件投降，結束戰爭。1945年8月21日今井武夫飛抵芷江洽降。 [1] 1945年9月2日上午9時，標誌著二戰結束的日本投降簽字儀式，在停泊在東京灣的密蘇里號主甲板上舉行。
維基百科：《日本投降》https://zh.wikipedia.org/wiki/%E6%97%A5%E6%9C%AC%E6%8A%95%E9%99%8D
銘記歷史 勿忘國恥 吾輩自強
