開發問題記錄(這部分還是比較零碎)

餘月七 2021-08-15 18:02:36 阅读数:966

本文一共[544]字,预计阅读时长:1分钟~
部分 零碎

本人才疏學淺,以下內容是個人查看各種文章以及搜索資料所寫出來的,所以如以下內容有不合適的地方,請及時糾正我,不吝賜教,本人在這不勝感激

前言

沒有總結過這塊的知識,因為平時這塊也是接觸不是很深,所以基本就是用的時候在去搜查找資料,時間一長一些東西也就記不住了,在此將一些以前學過的以及現在在補充學習的內容寫出來,也是為了翻一下自己的舊賬,以及去思考自己下一步去做什麼。
在此也要提前說明,以下出現的參考文章沒有任何打廣告的嫌疑,只不過是自己當時看的文章。


一、中間件

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更適合⼀些項⽬的開發吧。
當然這只是我看到的一些內容,因為個人也是沒有接觸過這類項目的開發,沒有體驗過。

image

如果還需要認識,可以參考以下文章(並無任何打廣告的意圖,全是網上搜的看的資料)

************************************************************************************************

面試連環炮系列(五):你們的項目為什麼要用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主“不高興就喝水”
image

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 SolrElasticSearch之間有很多比較可用,因此我將參考我自己認為最有用的那些,即涵蓋最重要的方面:

  • 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 服務,可讓您輕松在雲中部署、操作和擴展內存緩存
    • 請注意,Amazon ElastiCache 與 Memcached 協議兼容,Memcached 是一種廣泛采用的內存對象緩存系統,因此您今天在現有 Memcached 環境中使用的代碼、應用程序和流行工具將與該服務無縫協作(有關詳細信息,請參閱Memcached)。

[强調我的]
也許這已經以某種方式與以下兩種相關技術混淆了:

  • 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 版本開始,除了通過libvirtLXCsystemd-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

銘記曆史 勿忘國耻 吾輩自强
image
image

版权声明:本文为[餘月七]所创,转载请带上原文链接,感谢。 https://gsmany.com/2021/08/20210815180212823w.html