物聯網云的存盤與應用架構
- 存盤框架
- 資料型別
- 資料的存盤系統-資料庫
- SQL-傳統的關系型資料庫
- NoSQL-新型資料庫
- MongoDB
- Cassandra
- Redis
- influxDB
- Elasticsearch
- CAP理論
- 資料倉庫Data Warehouse
- 資料湖 Data Lake
- ETL/ELT
- 資料湖面臨的挑戰
- 資料湖的檔案系統
- 資料湖分層
- 物聯網云應用 Microservice
- 資料結構
- 單體架構(monnlithic architecture)
- Microservice
- SOA(service-oriented architecture)
- API Gateway
- 服務呼叫[Invocation]
- 服務發現
- 服務暫存器
- 部署策略
存盤框架

存盤體系可以大分類為三種,分別是冷暖熱存盤,
冷存盤表示存盤空間巨大且可以存盤不同結構的資料,但是呼叫緩慢,大部分資料需要進行轉換處理才能被使用,存盤資料的量最大,性能最低,安全性最高,
熱存盤則是表示經常被使用的資料,它們存在資料庫中,這些資料因為經常被使用,在網路上傳輸次數也多,所以安全性相對最低,但是由于靠近記憶體,呼叫速度最快效率最高,因此性能最佳,記憶體造價高昂,因此存盤資料的提及最小,
暖存盤介于二者之間,各項屬性相對均衡,
三種存盤對應的資料存盤結構分別是資料湖,資料倉庫和資料庫,這三類結構將在下文詳細介紹,
資料型別
資料可以分為以下幾類
- 結構資料[structured]:很容易找到的資料,在關系型資料庫中存盤,總是可以用表格(行和列)表達資料關系
- 非結構資料[unstructured]:關系型資料庫很難描述的資料,如郵件文本,文本檔案,音頻影像等,
- 半結構資料[semi-structure]: 非結構資料的一些特別標示符,如郵件文本雖然是非結構資料,但是郵件的發送日期,發送人,收信人等確實可以用表格來表示關系,照片的拍攝日期,地點,PID等都屬于非結構資料中的結構資料,也就是半結構資料,
- 多型資料[polymorphic]:資料的不同型別,如整數型,浮點數形,字串等多種資料型別,
資料的存盤系統-資料庫
2個構成要素,資料庫在硬碟上以檔案的形式上存盤并由作業系統呼叫資料庫的資料,程式的執行需要在記憶體上執行,沒有程式硬體上的資料無法被可視化,這里的acess指的是增刪查改, 程式分為用戶和系統程式(User/system)
SQL-傳統的關系型資料庫

傳統關系型資料庫,可以使用表格來表示其固有屬性,為了方便稱呼,我們將關系型資料庫縮寫RDB作為本文中的名稱,RDBMS則是關系型資料庫管理系統,

關系型資料庫有一個表重要的概念——范式,將資料無冗余的存盤在資料庫中從而提高對資料操作的效率,
第一范式: 無重復的列,資料不可再分即可,即如果有一列名為人類,且資料庫有男人和女人兩屬性,則該資料庫不滿足第一范式,
第二范式: 資料庫本身是第一范式且列元素均從屬于主鍵,
第三范式: P->Q->R,資料庫關系存在傳遞性,不屬于主鍵的所有屬性全部依賴于主鍵且沒有內部依賴,

事務的ACID:資料庫的操作以事務的形式進行,事務有四個性質以保證資料庫的正確性,
Atomicty: 原子性,事務要么執行,要么不執行,不能部分執行,如A給B轉賬一百元,完成這個操作需要從A的賬戶-100再給B的賬戶+100,這個事務不能存在A扣款了但是B的金額未增加,或者B增加了金額A未扣款,
Consistency: 一致性, 事務不論成功與否,執行后不影響事務的完全約束條件,即這稿操作無論如何,進行變動的總額度為0,即一個人-100一個人+100,其和為0,不會憑空出現資料的增減,
Isolation: 隔離性,一個事務的結果不會影響其他事務的執行的結果,很好理解,A和B的交易與D和C的交易是兩個獨立的事務,兩個事務不會對彼此的事務產生影響,如果是A-B,B-C交易的兩個事務,因為兩個事務有訪問共同資源,這是使用鎖【lock】機制,保證當一個事務執行完成后才可以對另一個事務進行執行權的賦予,
Durability: 持續性, 事務完成后,不可回滾資料庫,即當轉賬已經完成,不會因為網路原因,掉電事故等導致交易重置,
以上就是RDB的核心知識,DRB使用表格-行列的形式存盤關系型資料,關系型資料均為結構資料,
NoSQL-新型資料庫
NoSQL=Not Only SQL/ Not SQL,NOSQL是一個廣泛的術語,涵蓋了解決幾個關鍵主題的各種技術,如非關系、分布式、開源和水平可伸縮,NoSQL資料庫旨在滿足大型、分布式資料存盤需求,通常用于大資料和實時使用的web應用程式,NoSQL包含了多種資料庫技術,可以容納多型、非結構化、半結構化或結構化資料,
NoSQL可以分為以下四類:

K-V:實作結構非常簡單,旨在以無模式的方式存盤由索引鍵和值組成的資料,
Document: 檔案類,可以在DB中存盤任意資料型別(多型資料),沒有空列,可以存盤半結構資料,每個檔案都有一個檢索特定檔案所需的惟一鍵,該檔案旨在存盤、管理和檢索半結構化的面向檔案的資料

Column:寬列存盤,這些資料庫不是將資料存盤在一行中,而是將資料表存盤在垂直列中,雖然這聽起來像是簡單的水平和垂直調整,但列存盤實際上提供了高質量的性能和極其可伸縮的架構
Graph:使用圖論,設計資料表示為相互關聯的元素之間的關系數目未定的圖,更好的表達資料之間的關系,
所以,簡單的總結一下SQL/NoSQL的取舍,如下圖所示,

當資料出現非結構資料,不支持ACID,要求分布式系統處理等,使用NoSQL,而當資料是結構資料且想要高效快速處理資料,則使用SQL,
下面是幾個NoSQL資料庫的典例,
MongoDB

MongoDB是一個面向檔案的跨平臺資料庫,提供高性能和資料可用性,同時易于擴展; MongoDB能夠支持不同的模式、平衡負載、處理復制、索引、查詢和歸檔,
如上圖所示是RDB與MongoDB的一些術語差距,
Collection: 基本的資料存盤單位集合,相當于RDB的表,資料的型別可以不同,但是需要相互之間存在關系,
Document: 基本的資料存盤單位,
Relationship:在MongoDB中,資料有兩種關聯方式,一種是全加入,一種是參考,全加入是A檔案全部加入B檔案,所有資料存在一個檔案內,這樣當一個檔案丟失另一個也會丟失,存在風險,參考則是在檔案A的結尾追加一個連接到B的鏈接,然后通過鏈接訪問檔案B,檔案AB在不同的地址保存,這樣一個資料丟失另一個不會丟失,但是同時通過鏈接訪問另一個資料對時間和CPU的開銷要比全加入大得多,
總體來說,MongoDB的優點是具有無模式存盤資料的靈活性,不需要在意存盤資料的型別,并且有類似SQL語言的高效處理資料的能力,很便利,其次,水平擴展MongoDB非常簡單,擴展性好,MongoDB是“面向物件的”,可以很容易地表示域中的任何物件結構,MongoDB使各種規模的組織能夠更快地構建資料驅動的應用程式,不需要將資料分散到不同的關系表中,所有資料只能在一個地方找到,
Cassandra

Cassandra是一個存盤高可用,無故障的大容量存盤半結構資料的去中心化分布式資料庫,它的資料存盤單位是以列為單位的,行被視為列的值,有CQL資料操作語言,查詢速度快,效率比SQL還要高,但是不支持RDB中的join,group by, Foreign key等形式的讀寫操作,

與DRB的基本構成等價關系如上圖所示,
它的構成要素:

- key sapce: 資料存盤的容器,至少也要有一個以上的基本單位(列),

- column families: 列族,基本的資料存盤單位的集合,行資訊為其值,能表示帶有順序的資料,這些資料體現了資料的結構,

- column:列,資料的基本存盤單位,可以存盤的值有列名,對應值和時間戳,

- super column: 超級列, 超級列是惟一的,存盤子列和鍵值的映射關系,有唯一的列名和數量,
綜上所述,Cassandra的優點概括一下
可伸縮性:高可伸縮性,允許添加新的硬體,以適應更高的客戶量和額外的資料,
Always On: 該結構不包含單點故障,并且可以持續地容納不會失敗的關鍵業務應用程式, 線性擴展性能隨著集群節點數量的增加而提高吞吐量,保持快速回應時間,
可適應資料存盤:存盤非結構化、半結構化和結構化資料,并可以根據需要伸縮以適應資料結構中的更改,
分布資料:有效地跨多個資料節點復制資料,以便在需要的地方分布資料,
事務屬性: 支持支持原子性、一致性、隔離性和持久性(ACID)事務, 高效寫運行在低成本的商用硬體上,在存盤數百tb資料的同時,寫得驚人地快,而不降低讀取能力,
總結即由于可追加硬體設備而擴張性強,分布式資料提供了高速處理能力和備份資料,低成本的商用硬體可以實作所有資料結構的存盤,且滿足ACID事務特點,
Redis

Redis可以處理所有資料型別的資料,如字串,鏈表,無序集合,有序集合,哈希值等,字串可以表示所有型別的資料,鏈表保留了資料的插入順序,哈希值對于資料庫操作很容易且保持映射關系,
優點是保證了所有的資料都在記憶體中,因此處理效率極高;作為持續的硬碟資料庫,讀寫均可且寫是可選擇的, 原子的資料庫操作方式保證了并發操作也可以保證精確度,這個資料庫比起存盤資料,作為工具在其他領域使用也是非常好的選擇,
influxDB

是一個對IoT設備而言非常好的資料庫,有效的存盤時間序列從而幫助IoT設備傳感器采集資料,有類SQL的專屬操作語言可以對資料庫進行高效操作,能夠高速讀寫且擴張性很好,
構成如下:
Time:每個fluxdb資料庫都包含一個時間列,該列存盤與相應資料相關聯的時間戳
Filed:欄位是資料結構中負責記錄真實資料值和元資料的鍵值對[ID],欄位由欄位值和欄位鍵組成,欄位鍵是字串并存盤元資料,欄位值可以是浮點數、字串、布林值或整數形式,作為一個時間序列資料庫,inflxdb要求每個欄位值與特定的時間戳相關聯
Tag:標簽由標簽值和標簽鍵組成,標簽值和鍵被維護為字串并表示元資料
Measurement:這也可以看作是一個SQL表,因為度量作為時間列、欄位和標記的容器
Relation policy: 保留策略描述了一個inflxdb資料庫存盤資料的時間(持續時間)以及集群中保留的資料副本的數量(復制因子),超過給定持續時間的資料將自動從資料庫中洗掉,一般情況下,最小保持時間為1小時,最大保持時間為無限長,
Sharding: 分片是指資料的水平磁區,每個磁區稱為一個分片,influxdb還利用分片來解決可伸縮性問題,每個分片保存特定系列集的壓縮實際資料,
Elasticsearch
ES是一個面向檔案的資料庫,用于保存、管理和檢索半結構化或面向檔案的資料,同時也是一個非常流行的搜索引擎
它的結構如下:
Cluster: 集群,集群是服務器(節點)的集合,當它們連接在一起時,可以保存完整的資料集,并為所有連接的服務器提供聯合索引和搜索功能,服務器的集合,用于聯合計算和檢索,提高處理效率,每個集群都有一個ID作為識別符號
Node: 服務器的個體,帶有整個集群的一部分資料,可以根據集群ID分配不同的節點給特定集群
- 主節點:負責
構建或消除索引,添加或洗掉節點,每次集群狀態發生變化時,主節點都會通知集群中的其他節點,每個集群一次只包含一個主節點 - 客戶端節點:通過充當“智能路由器”,它處理向主節點發送與集群相關的請求,以及向資料節點發送與資料相關的請求,
客戶端節點不包含資料,無法成為主節點,. - 資料節點: 每個節點都包含一個資料分片,并處理與資料相關的操作,集群中包含多個資料節點,如果集群中的一個資料節點應該停止,集群將繼續操作,并在其他節點上重新排列該節點的資料,
- 攝取節點: 在實際索引之前,它處理檔案的初步處理
Index: 索引是具有相似特征的檔案的集合,索引由唯一的名稱表示,該名稱在執行操作時用于參考索引,一個集群可以包含任意多的索引,

Document: 檔案只是以特定JSON格式組織的欄位的集合,每個檔案都屬于一個型別,并存盤在一個索引中,該索引與唯一識別符號(UID)相關聯,
Type/Mapping: 映射指的是在同一個索引中共享一組公共欄位的檔案集合,
Shard&Replica: 索引能夠存盤超出節點硬體能力的海量資料,

- 分片shard:可以水平分割或縮放內容體積,可以跨多個節點的分片分布和并行操作,從而提高性能和吞吐量
- Elasticsearch允許用戶創建索引碎片的一個或多個副本,稱為復制碎片或簡單地稱為“副本”,它在分片或節點故障的情況下提供了更高的可用性;因此,不應該將副本分配給創建它的原始分片的相同節點,它支持搜索量和吞吐量的可伸縮性,因為搜索可以同時在所有副本上執行
Elasticsearch默認允許每個索引分配5個主碎片和1個副本,這意味著如果集群中有兩個節點,該索引將有5個主碎片和5個后續副本(一個完整的副本),每個索引總共10個碎片
Aggregation: 聚合,Elasticsearch能夠支持聚合,使用戶能夠從資料中提取組或統計資訊,在Elasticsearch中,用戶可以執行生成點擊的搜索,并同時回傳聚合的結果,所有這些都在一個回應中

Logstach: 通常,Elasticsearch與Logstash一起使用,Logstash是一個開源的服務器端資料處理管道,它同時從大量資料源中獲取資料,將其轉換,然后將其傳輸到目標,分為三步,本別是資料獲取,資料轉換和資料傳送,資料獲取是以位元流的方式獲取各種原資料,然后將難以操作的原資料進行資料轉換,變為可方便操作的資料,然后將其傳輸給目的地,然后進行資料操作后,使用kibanna等工具將資料進行可視化處理 ,
CAP理論

CAP理論指的是如上圖所示的三種特性同時最多只能滿足兩種,另外一種必然無法滿足的特性,
CAP分別是一致性,可用性,和容錯性,一致性表示了節點的資料應該同步,一個資料操作完成后,分布式系統內的其他節點的對應資料也應該被更新,可用性表示每個請求必然有一個回應,不論成敗都應有一個ACK,換言之服務一直是可用的,容錯性表示即便出現了內部部分錯誤也應該繼續提供服務,
CP: 沒有A,不滿足可用性,即允許每個請求可用無回應,則可用保證網路內節點高同步和容錯性,即便網路出現故障,因為可用無視故障部分的相應,所以其他正常節點資料均可以同步且提供服務,
AP:沒有C,NoSQL的代表,每個節點使用本地資料,不保證資料一致性則可用保證有求必應和容錯,因為不要求同步資料,所以每一個節點可用無等待的處理對應事務從而滿足有求必應,且網路故障時直接回傳無法處理的結果,
CA:無P,資料要求高可用性和一致性資料,則此時網路故障時,除非整個網路無法運行不然無法提供部分服務,
資料倉庫Data Warehouse

資料倉庫的資料主要用于資料挖掘,資料分析,解決資料孤島問題,為了幫助企業商用化政策決策而制定的資料庫,只能處理結構資料,資料倉庫的資料存盤量大于資料庫,
資料倉庫與資料庫的區別:
資料倉庫存盤的主要是歷史資料,而資料庫存盤日常常用資料,RDB因為范式標準,冗余資料少,事務處理時間也少,實時作業性能高,主要處理當下資料;但是資料倉庫的建立目的不是為了處理事務,而是根據歷史進行資料分析,使用未范式的資料進行資料處理,用于歷史資料分析維護,
資料湖 Data Lake

儲存資料量最大,存盤所有結構的資料,且是原資料,這些原資料可能存在不完整,有錯誤,或者價值未知,當下技術不可控等特點,這些資料在呼叫時需要消耗大量時間,要求使用ETL/ELT進行操作,有著足夠的存盤能力,相應 資料管理系統很重要,如果沒有資料管理系統則會成為資料沼澤[swamp],

上圖是資料湖與其他RDB/資料倉庫的比較圖,
ETL/ELT

資料湖中的資料因為結構不一且資料的完整性和各種性質均不一致,導致這些資料無法直接用于分析或規范化處理,因此資料需要使用ETL/ELT操作來進行資料規范,
ELT分別是[Extract,Load,Transform]:資料提取,資料加載,資料傳輸,
整體程序如下:
E: 資料提取,從資料湖中提取目標資料集,該資料集資料雜亂不堪,無法直接處理,這一步需要確認源,資料湖資料量很大,確認源資料在哪并不容易,其次要定義介面,對資料提取的介面、源檔案或者系統的資料存檔進行說明,
L: 資料加載,將處理好的資料存盤到目標容器,可以是資料庫或者資料倉庫,這一步內可以使用快取來提高加載效率,如果是增量資料則使用MERGE,
T: 資料轉換,該步驟內將原資料首先進行資料清洗[clean],將不可用資料,重復資料,損壞資料等資料取出后,進行資料型別轉換,轉換成便于存盤的結構資料,然后將結構資料進行關聯[賦予關系],并準備加載,
資料湖面臨的挑戰
如果沒有描述性元資料和維護它的機制,資料湖就有變成資料沼澤的風險,
資料目錄:資料目錄使用戶能夠編譯和審查元資料和索引資料,以便它們成為可搜索的,一個索引,用于檢索資料湖的資料
資料質量:使用主資料管理(MDM),這是一個基礎程序,用于根據業務操作策略同步、分類、集中、組織、豐富或本地化主資料,它只兼容結構化資料,根據多種規則進行資料管理的標準
資料跟蹤:資料跟蹤指的是資料的來源、對它做了什么以及隨著時間的推移它的位置,擁有完整的資料審計跟蹤,包括原始資料、轉換資訊及其分析用途,是滿足大多陣列織目前面臨的資料安全監管要求的必要條件資料溯源保證資料的安全性
資料安全:主要是三個方面,分別是端到端的加密通信,網路隔離和基于權限的訪問控制,
資料湖的檔案系統

據湖系統主要由可擴展的資料存盤和分布式檔案系統組成,這些檔案系統通過將較大的檔案劃分為較小的塊或通過跨資料服務器池(資料節點)分配的磁區表來部署資料,此外,資料通常被復制到多個節點以提高容錯性,在這樣的分布式系統中,負載均衡器被用來增加可伸縮性,
例子: Hadoop分布式檔案系統(HDFS) & Amazon S3存盤服務(Amazon S3)
資料湖分層

強烈建議基于多層/多層(不少于兩層)設計資料湖,其中一層為隔離區,還強烈建議基于特定的用例將第二層劃分為幾個區域,需要注意的是,資料湖各層/磁區之間的資料傳輸需要一個計算資源來完成資料的轉換和處理,
每個階層有不同的作用,比如快取,AI識別,資料轉換,機械學習等,對應階層的資料格式,型別,屬性,用途都不相同,
物聯網云應用 Microservice
資料結構

位于云中的物聯網應用可以基于三種不同的架構進行設計,

當服務器創建一個應用時:所有的資料需求有四類,包括應用集成,DB訪問邏輯控制,應用業務邏輯和連接準備,
- Presentation: 處理所有介面,管理和路由傳入的請求到業務邏輯,并以特定的格式顯示回應
- Application Business Logic: 執行與請求關聯的特定業務規則,以準備回應,
- Database Access and Logic: 實作資料庫所需的邏輯存盤和檢索資料,
- Application Integration:合并其他服務
單體架構(monnlithic architecture)
優點: 開發簡單,測驗容易,部署容易,可伸縮性是通過在負載平衡器后面運行多個應用程式副本來實作的,
缺點: 資料更新速度慢,應用更新后需要重新部署資料,必須手動測驗,出現資料故障或bug時整個應用可能會全部崩潰,雖然擴展性好但有條件,如果構建塊模塊有不同的資源需求,擴展是困難的,
Microservice
解決了單體架構的問題點,使用多個小塊分布式處理,分散一個大塊的各項能力,小塊一般存盤在虛擬機或者容器(docker)中,有著負載均衡的優點,且開發獨立、速度快且維護容易,有快取時業務性能大幅增加,容易識別故障點并定點維護,維護時不妨礙其他小塊的服務繼續執行,可構建多功能戰略應用多重服務需求,但是開發難度比較大,對團隊技術要求比較高且對經濟需求也相對較高,
SOA(service-oriented architecture)
不能完全解決單體構造的問題,區域分解決,服務使用共享資源存盤的方式,磁區大小略大,每個塊既可以提供服務也可以使用服務,使用P2P網路內部通信便利,

有ESB問題,由于使用共享資源,當ESB出現問題,服務整體性能將受到影響,ESB可以作為單點故障摧毀SOA性能,而Microservice對此的抗性要高得多,
| 特征 | SOA | Micro |
|---|---|---|
| 故障抗性 | ESB是故障弱點,單一受損也會影響全域 | 單一節點受影響不會影響系統整體 |
| 共享資源 | 盡可能共享多的資源 | 盡可能獨立處理各項事務 |
| 資料更新 | 更新后需要重新啟動SOA | 更新內部節點不需要重啟整體網路 |
| 塊大小 | 相對較大,聯合計算 | 相對較小,獨立計算 |
| 資料存盤 | 共享資源 | 私有存盤本地資源 |
| Monolithic問題 | 部分解決 | 全部解決 |
API Gateway

API網關是應用程式的介面,一般呼叫幾個微服務實作APP功能,需要持續的開發和管理,API網關是作為系統入口點的應用程式/服務,API網關抽象了內部系統的體系結構,然后通過一組API來表示它,API網關還可以負責身份驗證、負載平衡、監控、靜態回應處理、快取和請求整形或管理
服務呼叫[Invocation]
個應用程式的組件使用函式呼叫或語言級方法相互呼叫(呼叫),而使用微服務體系結構功能的應用程式則使用許多機器和行程間通信行程作為分布式系統,
特性1:客戶端互動樣式[一對一/一對多]
特性2:通信是同步的還是異步的
當Micro服務使用分布式系統進行IPS行程間通信,呼叫App時使用,有幾種方式
Request/Response:客戶端等待及時的服務回應,有多種協議選項,但最受歡迎的兩個是REST和Thrift
Notifaction: 不要求ACK,直接發送
Request/異步回應:等待ACK但不會進入阻塞狀態
Publish/異步回應:等待指定時間,可以阻塞
Publish/Subscribe:客戶端發布訊息,該訊息可被感興趣的服務使用,
Representational State Transfer (REST): 一個行程間通信
(IPC)機制,通常依賴于HTTP,資源是REST的主要概念,資源是表示應用程式中的業務物件(如產品、客戶)或業務物件組合的概念,REST使用通過URL參考的謂詞操作資源,例如,
GET請求回傳一個資源表示,很可能以JSON物件或XML檔案的形式,而POST請求實際上創建了一個可以通過PUT請求更新的新資源
Apache Thrift:用于撰寫跨語言遠程程序呼叫(RPC)服務器和客戶端的框架,Thrift提供了c風格的介面描述語言(IDL)定義api,接下來,編譯器為各種編程語言創建代碼,如Java、c++、PHP、Ruby、Python和Node.js,Thrift能夠支持不同的訊息格式,如二進制、緊湊二進制和JSON,請注意,二進制是一種更有效的選擇,因為它占用更少的空間,比JSON更快地解碼,
服務發現
盡管基礎設施服務(例如訊息代理)通常有一個通過作業系統環境變數確定的固定靜態位置/地址,但由于應用程式服務使用動態分配的位置/地址,找到服務位置可能很困難,由于升級和自動伸縮,服務實體會發生變化,因此需要一個服務發現組件來定位每個服務,服務發現既可以由客戶端驅動,也可以由服務器驅動,
方式: lient-Side Discovery/Server-Side Discovery
客戶端在啟動應用時,會通過服務暫存器記錄當前的資訊,而客戶端可以通過檢索暫存器來獲取自己的當前資訊,對于服務期而言,則通過負載平衡裝置在啟動服務時查詢服務器暫存器的對應鵝湖段的資訊,從而通過這些資訊認證身份,
當服務器應用啟動時,使用這些資訊,當服務結束,從暫存器洗掉這些資訊,
服務暫存器
服務注冊中心是一種能夠跟蹤服務實體和網路位置資訊的資料庫,由于服務注冊中心是服務發現的一個重要組成部分,因此它必須保持最新,并且必須具有高可用性
部署策略
建一個單片應用程式需要使用一個或多個相同的大型應用程式副本,
單個微服務是具有自己的監視、資源和擴展需求的迷你應用程式,此外,每個服務必須有適當的記憶體、CPU和I/O資源,因此,部署單片系統的程序比部署微服務應用程式的程序簡單,

大體有以上四種方式,
- MSIPH: 資源共有,部署快,效率高,但是不提供隔離服務
- SSIPT-VM: 提供隔離,不搶占資源,可以管理微服務,但是部署速度慢,資源利用率低,開銷巨大(因為每一個虛擬機有一個OS,每個OS都是CPU開銷)
- SSIPT-Container: 解決資料孤島問題,能夠進行預案管理,沒有單獨的OS所以開銷小且啟動快速,但是容器與宿主機直接相連且共享宿主機資源,安全性上而言攻擊可能會破壞主機,且技術成熟度低于虛擬機
- SD:又稱FaaS,供應商處理具體的操作需求,用戶只需要自己編碼,處理速度快,因此整體使用最簡單,可以方便管理微服務,但是不適合長期部署,AWS請求要在300s內完成,服務必須無模式(Schemaless)
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/323223.html
標籤:其他
上一篇:近距離通信,引領萬物互聯新時代
