• 利用PoE技術為5G網絡中的新一代IoT和其他設備供電

    利用PoE技術為5G網絡中的新一代IoT和其他設備供電

    新一代5G技術能夠提供具有更高速度的先進移動互聯網連接,可助力實現各種IoT和大數據應用,從而創造新的商機。這些應用以空前的速度推動了將更多類型的受電設備(PD)連接到以太網網絡的需求,這些設備包括IP監控攝像頭、802.11ac和802.11ax接入點、LED燈具、5G小型基站以及其他IoT電器。以太網供電(PoE)技術給在5G部署中為這些設備供電帶來了諸多優勢,通過將供電設備(PSE)和受電設備(PD)的功率限值分別設定為90W和71.3W,最新的IEEE® 802.3bt標準讓這種可能性成為現實。 面臨的挑戰是如何部署支持這項最新一代PoE技術的PD,以便它們能夠與現有IEEE 802.3bt標準之前的2對和4對PD協同工作,也就是支持早期符合之前標準的通用PoE(UPOE)和HDBaseT供電(POH)規範的PD。如今,行業已經彌合了這種互操作性差距,可確保符合之前標準和全新IEEE 802.3bt-2018標準的PD能夠共用相同的以太網基礎設施,而無需更換現有的交換機或佈線。 通向IEEE 802.3bt之路 自2003年批准第一個PoE標準以來,PoE的應用範圍大幅增長,並且在新應用方面不斷取得進展。在簡化安裝、節省CAPEX和OPEX成本以及為全球使用提供統一且安全的電源標準方面,PoE擁有巨大優勢。 在新應用中影響PoE使用的主要限制因素是可用功率的大小。儘管15.4W的電源足以滿足大多數IP電話和802.11a/b/g接入點的需求,但卻不足以為IP視頻電話、802.11n和雲台變焦控制(PTZ)IP攝像機供電。因此,電氣電子工程師協會(IEEE)在2009年發佈了IEEE 802.3at標準,規定了功率為30W的PoE電源。 如今,需要更高的功率來為連接到以太網的其他設備(例如PTZ監控攝像頭、自助服務終端、POS終端、瘦客户端、802.11ac和802.11ax接入點、小型基站以及聯網LED照明)提供支持,而這類設備均可從PoE中受益。為了滿足這一需求,新的IEEE 802.3bt標準主要通過利用全部四對結構化佈線來提高PoE的最大可用功率。IEEE 802.3bt擴展了在初始協商期間交換的電源分類信息,可實現高效的電源管理功能,支持多個PoE等級,同時還可向後兼容。這些增強功能解決了更高功率和更高效PoE供電系統帶來的挑戰。 IEEE 802.3bt標準意向徵集(CFI)活動於2013年初開始,並於2018年9月獲得正式批准。由於新標準通過將PSE和PD的功率限值分別設定為90W和71.3W來拓展PoE的使用場景,因此它不但能夠滿足現有市場需求,還被普遍認為是PoE市場增長的主要推動因素。 不過,在IEEE 802.3bt實施之前,也有一些同步開展的工作在努力提高PD的供電性能。從IEEE 802.3af-2003 PoE標準開始,能夠通過兩對5e類(Cat5e)線纜為每個設備提供最高達15.4W的輸出功率。IEEE 802.3at-2009標準(也稱為PoE+)引入了支持30W輸出功率和25.5W負載功率的“Type 2”PSE/PD。後者主要是對第一個標準的擴展。隨後,HDBaseT聯盟對HDBaseT協議進行了標準化,允許通過Cat5e或更高標準的線纜將HDMI鏈路擴展到最長100m。2011年,HDBaseT聯盟創建了HDBaseT供電(PoH)標準,這項標準將四對線纜的最大供電功率擴展到95W。 下表彙總了IEEE 802.3bt之前的標準: 注1:如果通道長度已知,則擴展功率容量能夠實現最高95W的PD輸入功率。 IEEE 802.3bt添加了許多功能。除了引入Type 3和Type 4 PSE/PD以及通過四對線纜工作之外,這項標準還支持單簽名和雙簽名PD結構,並將等級5到等級8添加到了改進的雙向認證過程中。只要通道長度已知,就會添加自動分級功能,功率容量也會得到擴展。最後,這項標準還包含低功耗待機功能,並且支持採用PoE的10G-BASE-T。下表給出了在IEEE 802.3bt標準批准後提供的PoE功能。 注1:如果通道長度已知,則擴展功率容量能夠實現最高60W(Type 3)和90W(Type 4)的PD輸入功率。 IEEE 802.3bt標準的目標之一是符合ISO/IEC 60950中定義的有限電源和安全特低電壓(SELV)要求。但是,這種合規性意味着每個端口的功率都不能超過100W。儘管存在這一功率上限,但每個端口100W的功率仍足以滿足先前在原有IEEE標準下不支持的應用的需求,這樣便能擴展PoE端口部署的潛在數量。 確保互操作性 只有PSE能夠(在功率方面)支持PD並且兩者均符合標準,IEEE 802.3bt規範便可確保IEEE 802.3bt系統能夠自動與傳統Type 1和Type 2設備配合工作。如果PD需要更高的功率(IEEE 802.3bt PD)而PSE無法支持該PD(IEEE 802.3af/at PSE),那麼PD將保持關閉狀態,或者進入開啓狀態而只消耗來自PSE的可用功率。 最早提供這種互操作性的解決方案示例之一是Microchip的PSE芯片組,它實現了符合之前標準的交換機與符合新IEEE 802.3bt-2018標準的產品之間的互操作。該芯片組基於Microchip的早期PSE芯片組,用於實現已廣泛採用的PoH四對供電標準(適用於95W PD)。另外,它也是符合IEEE 802.3bt-2018標準的PoE供電器和中跨產品的核心,可為用户彌合互操作性差距。 通過在PD與現有交換機之間安裝符合IEEE 802.3bt-2018標準的PoE注入器和中跨,用户能夠為符合之前標準的PD與符合IEEE 802.3bt-2018標準的PD的任意組合供電。通過使用單端口和多端口選項,符合新IEEE 802.3bt標準的交換機也能夠為滿足之前標準的PD供電。 對於系統開發人員而言,IEEE 802.3af/at/bt PoE芯片組提供了可擴展性,能夠將支持符合之前標準和符合IEEE 802.3bt-2018標準的PoE所需的兩對和四對系統集成到單板設計中。這些芯片組必須能夠均衡整個系統的散熱,並且應包含構建PSE設備所需的所有管理器和控制器功能,這些設備可為每個端口提供90W至99.9W的功率,同時為IEEE 802.3bt Type 3(1-6級)和Type 4(7-8級)應用提供最多48個端口的支持。需要額外考慮的是,基於這些芯片組的系統應具有無需更改硬件即可通過軟件更新將早期標準升級到IEEE 802.3bt的能力。 開發人員的最後一個擔憂是能否保護PD免受反極性連接的影響,並減少提供IEEE 802.3bt Type 4 8級電源所需的電源空間和成本。藉助在PoE連接的供電側所使用的全橋整流器,最新的IEEE 802.3bt解決方案也解決了這一問題。 新的IEEE 802.3bt標準能夠通過四對Cat5e線纜及更高標準的線纜提供90W的功率。這一PoE等級預計是已定義的最高級別,因為更高的級別對於當今基礎設施中部署的現有線纜和連接器可能並不安全。此標準將取代目前提供60W/75W/95W的所有現有符合之前標準的解決方案,例如UPOE或4PPoE。PoE系統和設備供應商提供了實現這些新標準的路線圖,同時也為早期符合之前標準的實現方案(包括支持UPOE和POH規範的實現方案)提供支持。符合之前標準的PD和符合新IEEE 802.3bt-2018標準的PD在合理實現後可以共用相同的以太網基礎設施,而無需更換現有的交換機或線纜。

    Microchip 交換機 5G 以太網

  • Microchip嵌入式控制工程師在線培訓課程“Microchip University”現已開放註冊

    Microchip嵌入式控制工程師在線培訓課程“Microchip University”現已開放註冊

    由開發Microchip產品和設計工具的創新專家授課,講授如何在流行的各類嵌入式系統應用中更好地使用Microchip產品和設計工具 Microchip Technology Inc.(美國微芯科技公司)今日宣佈已開放註冊面向工程師的在線課程,涵蓋從C語言編程和密碼學等內容在內的各種嵌入式設計主題,幫助他們更有效地使用Microchip相關產品。Microchip University在線培訓課程提供了實現各種系統的最佳實踐,如物聯網(IoT)、藍牙、通用串行總線(USB)和控制器區域網(CAN)等通信協議,以及自舉程序和使用現場可編程門陣列(FPGA)的高速數據分析。 Microchip技術應用部門全球副總裁Ken Pye表示:“我們的客户現在可以隨時隨地獲得業界最全面的高質量通用嵌入式系統控制設計課程。這些免費課程將教授工程師如何更快、更有效地將新設計推向市場,同時最大限度地利用我們的產品和開發工具。我們一直致力於為客户提供關於我們產品的高質量培訓,通過開放在線課程,我們可以幫助各種經驗水平的工程師更方便地獲得培訓機會。” 以往,Microchip只在年度會議期間提供現場的專場培訓。如今,Microchip University已將相關培訓課程搬到了網上。工程師們可以學習如何使用Microchip的MPLAB®代碼配置器(MCC)和獨立於內核的外設(CIP),以及創建嵌入式Linux®應用的解決方案。培訓課程內容豐富,涵蓋了電機控制、電池充電基礎知識、電源、安全、模擬系統設計等方面的最佳實踐。Microchip University課程覆蓋Microchip的全線產品。

    Microchip Microchip 嵌入式 控制器區域網

  • 交流電機測試供電解決方案

    交流電機測試供電解決方案

    摘要:交流電機廣泛應用於多領域內,在使用過程中,電機通過軟起動方式直至滿功率工作。PSA可編程交流電源為交流電機性能測試提供操作便捷、功能豐富的測試供電方案,準確把握電機各階段啓動特性。 交流電機是一種將交流電的電能轉變為機械能的裝置,主要由一個用以產生磁場的電磁鐵繞組或分佈的定子繞組和一個旋轉電樞或轉子組成。因其結構簡單、工作效率高、製造方便等優勢,廣泛應用於工農業生產、交通運輸、商業及家用電器等領域。 交流電機測試過程中通常不能直接將其啓動至最大功率,尤其未配置調速功能電機。電機直接滿全功率啓動會產生過高的啓動電流,會導致供電設備輸出電壓跌落波動或觸發過流保護,導致無法正常啓動。通過緩慢增加電機工作電壓實現轉速逐漸達到預期設定值,也是俗稱電機軟啓動,顯著降低電機啓動電流,確保測試正常開展。ZLG-PSA6000系列可編程交流電源為交流電機提供便捷操作、精準供電的測試供電方案, 即LIST/STEP編程與調節輸出電壓的變化速率等兩種方案,實現交流電機供電緩慢提升。 一、LIST/STEP編程方案 PSA6000系列可編程交流電源STEP/LIST功能,允許靈活地設置起始電壓值、結束電壓值、電壓步進值以及每一步電壓的持續時間等,實現電壓由低至高步階式升高。 STEP設定界面圖 STEP編程輸出電壓 二、調節輸出電壓的變化速率 PSA6000系列可編程交流電源允許設定電壓的變化速率。通過改變電壓的變化速率,實現交流電機兩端輸入電壓由低至高線性的升高。 電壓的變化速率的設定界面 電壓按某變化速率輸出 ZLG PSA6000系列高性能可編程交流電源是具有高精度、寬範圍輸出的電網模擬輸出設備,輸出功率2~21kVA,輸出頻率超過5000Hz,支持輸出自校正能顯著提升輸出精度,集成豐富的前沿應用解決方案,為電子產品性能測試與品質驗證提供正常或異常供電工況,配備完善的保護功能(OVP/OCP/OPP/OTP 等),可輕鬆應對交流電機的研發、認證、生產等階段的複雜測試。

    致遠電子 致遠電子 交流電機 LISTSTEP編程

  • MySQL面試重點篇27問27答

    26、數據庫三大範式精講 第一範式 在任何一個關係數據庫中,第一範式(1NF)是對關係模式的基本要求,不滿足第一範式(1NF)的數據庫就不是關係數據庫。所謂第一範式(1NF)是指數據庫表的每一列都是不可分割的基本數據項,同一列中不能有多個值,即實體中的某個屬性不能有多個值或者不能有重複的屬性。 如果出現重複的屬性,就可能需要定義一個新的實體,新的實體由重複的屬性構成,新實體與原實體之間為一對多關係。在第一範式(1NF)中表的每一行只包含一個實例的信息。 簡而言之,第一範式就是無重複的列。 第二範式 第二範式(2NF)是在第一範式(1NF)的基礎上建立起來的,即滿足第二範式(2NF)必須先滿足第一範式(1NF)。第二範式(2NF)要求數據庫表中的每個實例或行必須可以被惟一地區分。 為實現區分通常需要為表加上一個列,以存儲各個實例的惟一標識。這個惟一屬性列被稱為主關鍵字或主鍵、主碼。第二範式(2NF)要求實體的屬性完全依賴於主關鍵字。 所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性,如果存在,那麼這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體,新實體與原實體之間是一對多的關係。為實現區分通常需要為表加上一個列,以存儲各個實例的惟一標識。 簡而言之,第二範式就是非主屬性非部分依賴於主關鍵字。 第三範式 滿足第三範式(3NF)必須先滿足第二範式(2NF)。簡而言之,第三範式(3NF)要求一個數據庫表中不包含已在其它表中已包含的非主關鍵字信息。 例如,存在一個部門信息表,其中每個部門有部門編號(dept_id)、部門名稱、部門簡介等信息。那麼在員工信息表中列出部門編號後就不能再將部門名稱、部門簡介等與部門有關的信息再加入員工信息表中。如果不存在部門信息表,則根據第三範式(3NF)也應該構建它,否則就會有大量的數據冗餘。 簡而言之,第三範式就是屬性不依賴於其它非主屬性。 27、數據庫三大範式精要總結 (1)簡單歸納: 第一範式(1NF):字段不可分; 第二範式(2NF):有主鍵,非主鍵字段依賴主鍵; 第三範式(3NF):非主鍵字段不能相互依賴。 (2)解釋: 1NF:原子性。字段不可再分,否則就不是關係數據庫;; 2NF:唯一性 。一個表只説明一個事物; 3NF:每列都與主鍵有直接關係,不存在傳遞依賴。 28、MySQL常見的存儲引擎InnoDB、MyISAM的區別?適用場景分別是? 1)事務:MyISAM不支持,InnoDB支持 2)鎖級別:MyISAM 表級鎖,InnoDB 行級鎖及外鍵約束 3)MyISAM存儲表的總行數;InnoDB不存儲總行數; 4)MyISAM採用非聚集索引,B+樹葉子存儲指向數據文件的指針。InnoDB主鍵索引採用聚集索引,B+樹葉子存儲數據 適用場景: MyISAM適合:插入不頻繁,查詢非常頻繁,如果執行大量的SELECT,MyISAM是更好的選擇, 沒有事務。 InnoDB適合:可靠性要求比較高,或者要求事務;表更新和查詢都相當的頻繁, 大量的INSERT或UPDATE 29、事務四大特性(ACID)原子性、一致性、隔離性、持久性? 第一種回答 原子性:一個事務(transaction)中的所有操作,要麼全部完成,要麼全部不完成,不會結束在中間某個環節。。事務在執行過程中發生錯誤,會被恢復(Rollback)到事務開始前的狀態,就像這個事務從來沒有執行過一樣。一致性:在事務開始之前和事務結束以後,數據庫的完整性沒有被破壞。這表示寫入的資料必須完全符合所有的預設規則,這包含資料的精確度、串聯性以及後續數據庫可以自發性地完成預定的工作。隔離性:數據庫允許多個併發事務同時對其數據進行讀寫和修改的能力,隔離性可以防止多個事務併發執行時由於交叉執行而導致數據的不一致。事務隔離分為不同級別,包括讀未提交(Read uncommitted)、讀提交(read committed)、可重複讀(repeatable read)和串行化(Serializable)。持久性:事務處理結束後,對數據的修改就是永久的,即便系統故障也不會丟失。 第二種回答 原子性(Atomicity) 原子性是指事務包含的所有操作要麼全部成功,要麼全部失敗回滾,因此事務的操作如果成功就必須要完全應用到數據庫,如果操作失敗則不能對數據庫有任何影響。 一致性(Consistency) 事務開始前和結束後,數據庫的完整性約束沒有被破壞。比如A向B轉賬,不可能A扣了錢,B卻沒收到。 隔離性(Isolation) 隔離性是當多個用户併發訪問數據庫時,比如操作同一張表時,數據庫為每一個用户開啓的事務,不能被其他事務的操作所幹擾,多個併發事務之間要相互隔離。 同一時間,只允許一個事務請求同一數據,不同的事務之間彼此沒有任何干擾。比如A正在從一張銀行卡中取錢,在A取錢的過程結束前,B不能向這張卡轉賬。關於事務的隔離性數據庫提供了多種隔離級別,稍後會介紹到。 持久性(Durability) 持久性是指一個事務一旦被提交了,那麼對數據庫中的數據的改變就是永久性的,即便是在數據庫系統遇到故障的情況下也不會丟失提交事務的操作。 30、SQL中的NOW()和CURRENT_DATE()兩個函數有什麼區別? NOW()命令用於顯示當前年份,月份,日期,小時,分鐘和秒。CURRENT_DATE()僅顯示當前年份,月份和日期。 31、什麼是聚合索引 ? 聚簇索引就是按照拼音查詢,非聚簇索引就是按照偏旁等來進行查詢。 其實,我們的漢語字典的正文本身就是一個聚集索引。比如,我們要查"安"字,就會很自然地翻開字典的前幾頁,因為"安"的拼音是"an",而按照拼音排序 漢字的字典是以英文字母"a"開頭並以"z"結尾的,那麼"安"字就自然地排在字典的前部。如果您翻完了所有以"a"開頭的部分仍然找不到這個字,那麼就 説明您的字典中沒有這個字;同樣的,如果查"張"字,那您也會將您的字典翻到最後部分,因為"張"的拼音是"zhang"。也就是説,字典的正文部分本身 就是一個目錄,您不需要再去查其他目錄來找到您需要找的內容。 我們把這種正文內容本身就是一種按照一定規則排列的目錄稱為"聚集索引" 32、什麼是非聚合索引? 如果您認識某個字,您可以快速地從自動中查到這個字。但您也可能會遇到您不認識的字,不知道它的發音,這時候,您就不能按照剛才的方法找到您要查的字,而 需要去根據"偏旁部首"查到您要找的字,然後根據這個字後的頁碼直接翻到某頁來找到您要找的字。 但您結合"部首目錄"和"檢字表"而查到的字的排序並不是 真正的正文的排序方法,比如您查"張"字,我們可以看到在查部首之後的檢字表中"張"的頁碼是672頁,檢字表中"張"的上面是"馳"字,但頁碼卻是63 頁,"張"的下面是"弩"字,頁面是390頁。 很顯然,這些字並不是真正的分別位於"張"字的上下方,現在您看到的連續的"馳、張、弩"三字實際上就是他 們在非聚集索引中的排序,是字典正文中的字在非聚集索引中的映射。 我們可以通過這種方式來找到您所需要的字,但它需要兩個過程,先找到目錄中的結果,然後 再翻到您所需要的頁碼。 我們把這種目錄純粹是目錄,正文純粹是正文的排序方式稱為"非聚集索引"。 33、聚集索引與非聚集索引的區別是什麼? 非聚集索引和聚集索引的區別在於, 通過聚集索引可以查到需要查找的數據, 而通過非聚集索引可以查到記錄對應的主鍵值 , 再使用主鍵的值通過聚集索引查找到需要的數據。聚集索引和非聚集索引的根本區別是表記錄的排列順序和與索引的排列順序是否一致。 聚集索引(Innodb)的葉節點就是數據節點,而非聚集索引(MyisAM)的葉節點仍然是索引節點,只不過其包含一個指向對應數據塊的指針。 34、創建索引時需要注意什麼? 非空字段:應該指定列為NOT NULL,除非你想存儲NULL。在 MySQL 中,含有空值的列很難進行查詢優化,因為它們使得索引、索引的統計信息以及比較運算更加複雜。你應該用0、一個特殊的值或者一個空串代替空值; 取值離散大的字段:(變量各個取值之間的差異程度)的列放到聯合索引的前面,可以通過count()函數查看字段的差異值,返回值越大説明字段的唯一值越多字段的離散程度高; 索引字段越小越好:數據庫的數據存儲以頁為單位一頁存儲的數據越多一次IO操作獲取的數據越大效率越高。唯一、不為空、經常被查詢的字段 的字段適合建索引 35、MySQL中CHAR和VARCHAR的區別有哪些? char的長度是不可變的,用空格填充到指定長度大小,而varchar的長度是可變的。 char的存取數度還是要比varchar要快得多 char的存儲方式是:對英文字符(ASCII)佔用1個字節,對一個漢字佔用兩個字節。varchar的存儲方式是:對每個英文字符佔用2個字節,漢字也佔用2個字節。 36、MySQL 索引使用的注意事項 MySQL 索引通常是被用於提高 WHERE 條件的數據行匹配時的搜索速度,在索引的使用過程中,存在一些使用細節和注意事項。 函數,運算,否定操作符,連接條件,多個單列索引,最左前綴原則,範圍查詢,不會包含有NULL值的列,like 語句不要在列上使用函數和進行運算 1)不要在列上使用函數,這將導致索引失效而進行全表掃描。 select * from news where id / 100 = 1 為了使用索引,防止執行全表掃描,可以進行改造。 select * from news where news_year = 2017 and news_month = 1 事實上,MySQL 只能使用一個單列索引。為了提高性能,可以使用複合索引 news_year_month_idx(news_year, news_month) 保證 news_year 和 news_month 兩個列都被索引覆蓋。 4)複合索引的最左前綴原則 複合索引遵守“最左前綴”原則,即在查詢條件中使用了複合索引的第一個字段,索引才會被使用。因此,在複合索引中索引列的順序至關重要。如果不是按照索引的最左列開始查找,則無法使用索引。假設,有一個場景只需要針對資訊的月份進行查詢,那麼,SQL 語句可以寫成: select * from news where news_weekth = 1 and enable = 1 然而,並不是所有的範圍查詢都可以進行改造,對於必須使用範圍查詢但無法改造的情況,我的建議:不必試圖用 SQL 來解決所有問題,可以使用其他數據存儲技術控制時間軸,例如 Redis 的 SortedSet 有序集合保存時間,或者通過緩存方式緩存查詢結果從而提高性能。 7)索引不會包含有NULL值的列 只要列中包含有 NULL 值都將不會被包含在索引中,複合索引中只要有一列含有 NULL值,那麼這一列對於此複合索引就是無效的。因此,在數據庫設計時,除非有一個很特別的原因使用 NULL 值,不然儘量不要讓字段的默認值為 NULL。 8)隱式轉換的影響 當查詢條件左右兩側類型不匹配的時候會發生隱式轉換,隱式轉換帶來的影響就是可能導致索引失效而進行全表掃描。下面的案例中,date_str 是字符串,然而匹配的是整數類型,從而發生隱式轉換。

    架構師社區 事務 範式 MySQL

  • 90 後少年,開源傳奇!

    大家好,我是小林。 今天給大家分享下小林一位朋友的大喜事。 先來介紹下這位朋友,他是位熱愛開源的 90 後小夥,同時也是愛貓咪的程序員,因此大家都稱他為喵大人。 喵大人一個人創辦了 Dromara 開源社區,自己一人也開源了很多分佈式事務框架,後面他的開源社區吸引了很多志同道合的朋友,社區也在逐漸擴大。 最近就發生了一個喜事,喵大人開源的分佈式網關框架 Soul,經過多位社區朋友的共同維護和努力,這個開源項目成功已經加入到了 Apache 基金會孵化階段。 喵大人和他社區的朋友們這股開源精神值得大家學習,期待未來他們的項目能成為頂級項目! 接下來,是「喵大人和他社區的朋友們」想説的。 北京時間 2021 年 5 月 3 日,Dromara 開源社區的 Soul 網關經過 Apache Incubator 的投票,正式步入 Apache 基金會孵化器。 根據投票結果,我們獲得了10個約束性投票(binding votes)和 7 個無約束性投票(non-binding votes)的投票,全部持贊同意見,無棄權票和反對票,投票順利通過。 隨後,Soul網關項目將改名為 ShenYu。 功能特點 提供了諸如限流、熔斷、轉發 、重寫、重定向、和路由監控等插件; 支持 HTTP、RESTFul、WebSocket、Dubbo、 GRPC、 Tars、 Spring Cloud 代理; 支持熱插拔,用户可以定製化開發; 為了靈活的適配,選擇器和規則可以動態的適配; 支持集羣部署; 支持 A/B 測試和灰度發佈。 模塊 soul-admin : 插件和其他信息配置的管理後台 soul-bootstrap : 用於啓動項目,用户可以參考 soul-client : 用户可以使用 Spring MVC,Dubbo,Spring Cloud 快速訪問 soul-disruptor : 基於disruptor的封裝 soul-register-center : 為soul-client提供各種rpc接入註冊中心的支持 soul-common : 框架的通用類 soul-dist : 構建項目 soul-metrics : prometheus(普羅米修斯)實現的 metrics soul-plugin : Soul 支持的插件集合 soul-spi : 定義 Soul spi soul-spring-boot-starter : 支持 spring boot starter soul-sync-data-center : 提供 ZooKeeper,HTTP,WebSocket,Nacos 的方式同步數據 soul-examples : RPC 示例項目 soul-web : 包括插件、請求路由和轉發等的核心處理包 插件化設計 無論請求何時進入,Soul 會通過響應鏈執行所有已打開的插件。 插件是 Soul 的靈魂,並且插件也是可擴展和熱插拔的。 不同的插件實現不同的功能。 當然,用户也可以定製化插件去滿足他們自己的需求。 如果你有定製化插件的需求,請參看這裏://dromara.org/zh/projects/soul/custom-plugin/ 數據緩存 & 數據同步 所有的數據都被緩存在 JVM 的 ConcurrentHashMap 中,所以它非常快。 當用户在後台界面改變配置信息時,Soul 通過監聽 ZooKeeper node,WebSocket push,HTTP longPull 來動態更新緩存。 為什麼叫神禹 ShenYu (神禹)是我們古代君王夏禹的尊稱(後世也尊稱大禹),為造福百姓,成功治理黃河水患,留下了三過家門而不入的感人故事。其和堯舜並稱為中國古代最偉大的三位君王 首先,取名為ShenYu是弘揚我們中華文明的傳統美德。 其次,網關最最重要的是對流量的治理。 最後,社區將會以公平,公正,公開,任人唯賢的做事方式,致敬神禹的同時也非常符合Apache Way。 感謝 我在 2018 年 3 月寫下 soul 網關的第一行代碼和創立 Dromara 開源社區的時候,並沒有想到過,社區的力量是如此的強大,社區的同學會如此的熱情,非常感謝每一位同學提交的代碼,寫下的每一篇源碼解析的文章,參與的每一次分享活動以及每一個Issue。 感謝 Apache 基金會孵化器的每一位導師,他們耐心的佈道,提供了建設性的意見,讓孵化之路更加通暢。 在進入 Apache 基金會孵化器後,社區將謹遵 Apache Way,這是我們的新挑戰,新啓航! 最後,如果大家想了解 ShenYu 開源項目,可以點擊「閲讀原文」,跳轉到 Github。 免責聲明:本文內容由21ic獲得授權後發佈,版權歸原作者所有,本平台僅提供信息存儲服務。文章僅代表作者個人觀點,不代表本平台立場,如有問題,請聯繫我們,謝謝!

    小林coding 開源 Dromara ShenYu

  • 為什麼看起來不是很複雜的網站,卻需要大量頂尖高手來開發?

    為什麼很多看起來不是很複雜的網站,比如 Facebook 需要大量頂尖高手來開發? 子柳: 就拿淘寶來説説,當作給新人一些科普。 先説你看到的頁面上,最重要的幾個: 搜索商品:這個功能,如果你有幾千條商品,完全可以用select * from tableXX where title like %XX%這樣的操作來搞定。但是——當你有10000000000(一百億)條商品的時候,任何一個數據庫都無法存放了,請問你怎麼搜索?這裏需要用到分佈式的數據存儲方案,另外這個搜索也不可能直接從數據庫裏來取數據,必然要用到搜索引擎(簡單來説搜索引擎更快)。好,能搜出商品了,是否大功告成可以啵一個了呢?早着呢,誰家的商品出現在第一頁?這裏需要用到巨複雜的排序算法。要是再根據你的購買行為做一些個性化的推薦——這夠一幫牛叉的算法工程師奮鬥終生了。 商品詳情:就是搜索完畢,看到你感興趣的,點擊查看商品的頁面,這個頁面有商品的屬性、詳細描述、評價、賣家信息等等,這個頁面的每天展示次數在30億以上,同樣的道理,如果你做一個網站每天有10個人訪問,你絲毫感覺不到服務器的壓力,但是30億,要解決的問題就多了去了。首先,這些請求不能直接壓到數據庫上,任何單機或分佈式的數據庫,承受30億每天的壓力,都將崩潰到完全沒有幸福感,這種情況下要用到的技術就是大規模的分佈式緩存,所有的賣家信息、評價信息、商品描述都是從緩存裏面來取到的,甚至更加極致的一點“商品的瀏覽量”這個信息,每打開頁面一次都要刷新,你猜能夠從緩存裏面來取嗎?淘寶做到了,整個商品的詳情都在緩存裏面。 商品圖片:一個商品有5個圖片,商品描述裏面有更多圖片,你猜淘寶有多少張圖片要存儲?100億以上。這麼多圖片要是在你的硬盤裏面,你怎麼去查找其中的一張?要是你的同學想拷貝你的圖片,你需要他準備多少塊硬盤?你需要配置多少大的帶寬?你們的網卡是否能夠承受?你需要多長時間拷貝給他?這樣的規模,很不幸市面上已經沒有任何商業的解決方案,最終我們必須自己來開發一套存儲系統,如果你聽説過google的GFS,我們跟他類似,叫TFS。順便説一下,騰訊也有這樣的一套,也叫TFS。 廣告系統:淘寶上有很多廣告,什麼,你不知道?那説明我們的廣告做的還不錯,居然很多人不認為它是廣告,賣家怎麼出價去買淘寶的廣告位?廣告怎麼展示?怎麼查看廣告效果?這又是一套算法精奇的系統。 BOSS系統:淘寶的工作人員怎麼去管理這麼龐大的一個系統,例如某時刻突然宣佈某位作家的作品全部從淘寶消失,從數據庫到搜索引擎到廣告系統,裏面的相關數據在幾分鐘內全部消失,這又需要一個牛叉的後台支撐系統。 運維體系:支持這麼龐大的一個網站,你猜需要多少台服務器?幾千台?那是零頭。這麼多服務器,上面部署什麼操作系統,操作系統的內核能否優化?Java虛擬機能否優化?通信模塊有沒有榨取性能的空間?軟件怎麼部署上去?出了問題怎麼回滾?你裝過操作系統吧,優化過吧,被360坑過沒,崩潰過沒?這裏面又有很多門道。 不再多寫了,除了上面提到的這些,還有很多很多需要做的技術,當然並不是這些東西有多麼高不可攀,任何複雜的龐大的東西都是從小到大做起來的,裏面需要牛叉到不行的大犇,也需要充滿好奇心的菜鳥,最後這一句,你當我是別有用心好了。 知乎網友@蔡正海 : 剛看了一篇很有意思的文章,講的很清楚——《你剛才在淘寶上買了一件東西》 你發現快要過年了,於是想給你的女朋友買一件毛衣,你打開了淘寶網址。這時你的瀏覽器首先查詢DNS服務器,將淘寶網址轉換成ip地址。不過首先你會發現,你在不同的地區或者不同的網絡(電信、聯通、移動)的情況下,轉換後的IP地址很可能是 不一樣的,這首先涉及到負載均衡的第一步,通過DNS解析域名時將你的訪問分配到不同的入口,同時儘可能保證你所訪問的入口是所有入口中可能較快的一個 (這和後文的CDN不一樣)。 你通過這個入口成功的訪問了淘寶官網的實際的入口IP地址。這時你產生了一個PV,即Page View,頁面訪問。每日每個網站的總PV量是形容一個網站規模的重要指標。淘寶網全網在平日(非促銷期間)的PV大概是16-25億之間。同時作為一個獨立的用户,你這次訪問淘寶網的所有頁面,均算作一個UV(Unique Visitor用户訪問)。最近臭名昭著的12306的日PV量最高峯在10億左右,而UV量卻遠小於淘寶網十餘倍,這其中的原因我相信大家都會知道。 因為同一時刻訪問淘寶的人數過於巨大,所以即便是生成淘寶首頁頁面的服務器,也不可能僅有一台。僅用於生成淘寶官網首頁的服務器就可能有成百上千台,那麼你的一次訪問時生成頁面給你看的任務便會被分配給其中一台服務器完成。這個過程要保證公正、公平、平均(暨這成百上千台服務器每台負擔的用户數要差不多),這一很複雜的過程是由幾個系統配合完成,其中最關鍵的便是LVS(Linux Virtual Server),世界上最流行的負載均衡系統之一,正是由目前在淘寶網供職的章文嵩博士開發的。 經過一系列複雜的邏輯運算和數據處理,用於這次給你看的淘寶網首頁的HTML內容便生成成功了。對web前端稍微有點常識的童鞋都應該知道,下一步瀏覽器會去加載頁面中用到的css、js、圖片、腳本和資源文件。但是可能相對較少的同學才會知道,你的瀏覽器在同一個域名下併發加載的資源數量是有限制的,例如IE6-7是兩個,IE8是6個,Chrome各版本不大一樣,一般是4-6個。我剛剛看了一下,我訪問淘寶網首頁需要加載126個資源,那麼如此小的併發連接數自然會加載很久。所以前端開發人員往往會將上述這些資源文件分佈在好多個域名下,變相的繞過瀏覽器的這個限制,同時也為下文的CDN工作做準備。 據不可靠消息,在雙十一當天高峯,淘寶的訪問流量最巔峯達到871GB/S。這個數字意味着需要178萬個4Mb帶寬的家庭寬帶才能負擔的起,也完全有能力拖垮一箇中小城市的全部互聯網帶寬。那麼顯然,這些訪問流量不可能集中在一起。並且大家都知道,不同地區不同網絡(電信、聯通等)之間互訪會非常緩慢,但是你卻發現很少發現淘寶網訪問緩慢。這便是CDN(Content Delivery Network),即內容分發網絡的作用。淘寶在全國各地建立了數十上百個CDN節點,利用一些手段保證你訪問的(這裏主要指js、css、圖片等)地方是離你最近的CDN節點,這樣便保證了大流量分散在各地訪問的加速節點上。 這便出現了一個問題,那就是假若一個賣家發佈了一個新的寶貝,上傳了幾張新的寶貝圖片,那麼淘寶網如何保證全國各地的CDN節點中都會同步的存在這幾張圖 片供用户使用呢?這裏邊就涉及到了大量的內容分發與同步的相關技術。淘寶開發了分佈式文件系統TFS(Taobao File System)來處理這類問題。 好了,這時你終於加載完了淘寶首頁,那麼你習慣性的在首頁搜索框中輸入了'毛衣'二字並敲回車,這時你又產生了一個PV,然後,淘寶網的主搜索系統便開始為你服務了。它首先對你輸入的內容基於一個分詞庫進行分詞操作。眾所周知,英文是以詞為單位的,詞和詞之間是靠空格隔開,而中文是以字為單位,句子中所有的字連起來才能描述一個意思。例如,英文句子I am a student,用中文則為:“我是一個學生”。計算機可以很簡單通過空格知道student是一個單詞,但是不能很容易明白“學”、“生”兩個字合起來才表示一個詞。把中文的漢字序列切分成有意義的詞,就是中文分詞,有些人也稱為切詞。我是一個學生,分詞的結果是:我 是 一個學生。 進行分詞之後,還需要根據你輸入的搜索詞進行你的購物意圖分析。用户進行搜索時常常有如下幾類意圖: 瀏覽型:沒有明確的購物對象和意圖,邊看邊買,用户比較隨意和感性。Query例如:”2010年10大香水排行”,”2010年流行毛衣”, “zippo有多少種類?”; 查詢型:有一定的購物意圖,體現在對屬性的要求上。Query例如:”適合老人用的手機”,”500元 手錶”; 對比型:已經縮小了購物意圖,具體到了某幾個產品。Query例如:”諾基亞E71 E63″,”akg k450 px200″; 確定型:已經做了基本決定,重點考察某個對象。Query例如:”諾基亞N97″,”IBM T60″。通過對你的購物意圖的分析,主搜索會呈現出完全不同的結果來。 之後的數個步驟後,主搜索系統便根據上述以及更多複雜的條件列出了搜索結果,這一切是由一千多台搜索服務器完成。然後你開始逐一點擊瀏覽搜索出的寶貝。你開始查看寶貝詳情頁面。經常網購的親們會發現,當你買過了一個寶貝之後,即便是商家多次修改了寶貝詳情頁,你仍然能夠通過‘已買到的寶貝’查看當時的快照。這是為了防止商家對在商品詳情中承諾過的東西賴賬不認。那麼顯然,對於每年數十上百億比交易的商品詳情快照進行保存和快速調用不是一個簡單的事情。這 其中又涉及到數套系統的共同協作,其中較為重要的是Tair,淘寶自行研發的分佈式KV存儲方案。 然後無論你是否真正進行了交易,你的這些訪問行為便忠實的被系統記錄下來,用於後續的業務邏輯和數據分析。這些記錄中訪問日誌記錄便是最重要的記錄之一, 但是前邊我們得知,這些訪問是分佈在各個地區很多不同的服務器上的,並且由於用户眾多,這些日誌記錄都非常龐大,達到TB級別非常正常。那麼為了快速及時 傳輸同步這些日誌數據,淘寶研發了TimeTunnel,用於進行實時的數據傳輸,交給後端系統進行計算報表等操作。 你的瀏覽數據、交易數據以及其它很多很多的數據記錄均會被保留下來。 使得淘寶存儲的歷史數據輕而易舉的便達到了十數甚至更多個PB(1PB=1024TB=1048576GB)。如此巨大的數據量經過淘寶系統1:120的極限壓縮存儲在淘寶的數據倉庫中。並且通過一個叫做雲梯的,由2000多台服務器組成的超大規模數據系統不斷的進行分析和挖掘。 從這些數據中淘寶能夠知道小到你是誰,你喜歡什麼,你的孩子幾歲了,你是否在談戀愛,喜歡玩魔獸世界的人喜歡什麼樣的飲料等,大到各行各業的零售情況、各類商品的興衰消亡等等海量的信息。 説了這麼多,其實也只是敍述了淘寶上正在運行的成千上萬個系統中的寥寥幾個。即便是你僅僅訪問一次淘寶的首頁,所涉及到的技術和系統規模都是你完全無法想 象的,是淘寶2000多名頂級的工程師們的心血結晶,其中甚至包括長江學者、國家科學技術最高獎得主等眾多大牛。同樣,百度、騰訊等的業務系統也絕不比淘寶簡單。你需要知道的是,你每天使用的互聯網產品,看似簡單易用,背後卻凝聚着難以想象的智慧與勞動。 免責聲明:本文內容由21ic獲得授權後發佈,版權歸原作者所有,本平台僅提供信息存儲服務。文章僅代表作者個人觀點,不代表本平台立場,如有問題,請聯繫我們,謝謝!

    架構師社區 淘寶 Facebook

  • ERP已死,“中台”已涼,“低代碼”稱王!

    業界有個説法,認為ERP經過了20多年的發展,理念已經不行了、跟不上時代了;而後起之秀“中台”,經歷了興起、火爆、被唱衰等階段,也已經涼涼了。 再加上,最近一年“低代碼”、“零代碼”的迅速崛起,似乎企業數字化領域又要“改朝換代”了。 難道ERP“死”了,“中台”涼了,“低代碼”要稱王了? 其實,企業數字化領域從來都不缺新概念,每隔幾年就來一波。但是,在企業裏搞數字化轉型的朋友就懵圈了,這麼多新概念出來,你們倒是很“敏捷”,可是企業消化不了呀。 企業裏的MRP2 報表數字還沒對齊,中台就來了,説是要“去煙囱”化,花了幾千萬上“中台”。剛把“數據孤島”打通,又説要搞“低代碼”了,要幹掉程序員,把企業數字化的能力重新交回給業務人員。 01 ERP,中台,低代碼的本質是什麼? 我們先來思考Why的問題,ERP、中台、低代碼的本質是什麼? 任何的企業管理軟件都只是技術手段,技術解決的是業務的問題,企業治理軟件的本質就是企業治理思想的體現。 所以,企業購買軟件,實際上買的是企業治理方法論。是要解決企業運作過程中出現的問題,是要降本增效。否則excel表格就夠了,要説靈活的話,哪個軟件比excel更靈活? 那麼,從ERP,到中台,再到低代碼,演進的邏輯是什麼? 先説結論,從根本上來説就是企業治理的主要矛盾發生了變化。 1、ERP解決的是,企業大規模生產管理問題 ERP,是由美國Gartner公司於1990年提出的。但是ERP的起源則是要追溯到1965年,針對當時企業出現的供應滯後、交貨不及時等問題,APICS協會提出了MRP(物料需求計劃)的概念。通過MRP管理軟件的信息集成系統,企業對生產製造過程中的“銷、產、供”等實現了信息集成,使得企業在庫存管理上進行有效的計劃和控制。 2、中台解決的是,企業快速創新的問題 “大中台,小前台”,是阿里巴巴在2015年提出來的概念,通過合併相似組織,沉澱核心能力到中台,很好地支撐前台快速試錯、快速創新。極大釋放企業創新和變革的能力,如盒馬鮮生、釘釘就是阿里中台創新的成果。 之前,老K的文章説過阿里開始“拆”中台、把中台做薄,也是為了更好的支撐阿里的“五新”戰略,幫助阿里打造出顛覆式創新業務,如:代表着新制造的“犀牛製造”等等。 3、“低代碼”滿足了企業“敏捷能力”的訴求 老K、流水姐寫過不少低代碼的文章,低代碼之所以這兩年火了,得益於中小企業對“敏捷能力”的迫切需求。 最近幾年,由於疫情、中美關係等外部環境的變化,導致企業的經營策略發生改變。比如線下培訓機構要轉變成線上線下結合的模式、國內電商公司都紛紛出海。越來越多的企業意識到“敏捷能力”的重要性。 “低代碼”、“零代碼”幫助企業快速建立“敏捷能力”:即買即用、工具模板化、支持少量定製,雲端部署,實時在線。 比如,一家傳統培訓機構,在疫情期間,一週之內就部署完成:在線課堂、教師管理、員工管理、客户管理、客服管理等模塊。如果按照傳統的方式來建設系統,需定製開發或購買套件、採購服務器、買帶寬/租IDC、培訓員工等等。 如果使用“低代碼”平台,只要購買SAAS服務模板、對員工進行簡單的培訓,就可以對一個全新業務模式進行MVP試錯。這在以前是不可想象的。 總結一下,ERP、中台、低代碼的本質是企業治理方法論,其演進的底層邏輯就是,企業治理的主要矛盾發生了變化。 02 企業數字化轉型方法論 下面介紹兩個具有代表性的企業數字化轉型方法論,一個國內的,一個國外的。 一、華為的“企業數字化轉型1234法” 華為在2019年發表了白皮書《企業數字化轉型方法論》,正式提出了:企業數字化轉型“1234法”。 該方法論包含4個部分: 一個戰略。就是要把企業數字化轉型戰略,定為企業的一級戰略,進行全局謀劃,配備戰略級資源的支持。 二個保障。通過組織轉型,激發組織活力;通過文化轉型,創造轉型氛圍。 三個核心原則。戰略統籌、技術業務驅動、自主&合作並行作為三個核心原則。將核心原則貫穿轉型全過程,保證轉型始終在正確的道路上。 四個關鍵行動。包括頂層設計、平台賦能、生態協同、持續迭代,通過四個關鍵行動控制轉型關鍵過程。 感興趣的話可以去下載該白皮書來研究,篇幅有限就不展開了,否則推文就變成論文了。 二、埃森哲數字化轉型“三步曲” 埃森哲數字化轉型方法論,圍繞企業三大價值維度:數字化運營、主營業務增長、商業創新。 埃森哲的方法論,既具有科學性,也很接地氣。其實企業轉型的根本目的就是提升運營效率,驅動業務增長,激化業務創新。並不是去追什麼新的概念。 埃森哲的企業數字化方法論,提出了轉型三步曲: 第一步:制定數字化轉型目標 企業領導層需要對未來技術發展、行業發展、消費者趨勢等諸多因素進行綜合分析,定義對本公司最優的數字化目標。 比如沃爾瑪的轉型目標就是提升營銷精準度,他們建立了基於用户行為和偏好的算法模型,為用户推送最感興趣的商品,為沃爾瑪帶來了10%~15%的交易量提升。 第二步:採取數字化轉型行動 企業需要在全公司範圍內提升各方對數字化轉型的認同感,並建立起數字化思維方式。 為打造數字化企業,企業應當藉助產業物聯網、人工智能和敏捷創新等數字技術對其運營進行改造升級,提高內部運營效率。 比如,一家日本連鎖便利店,採集並分析了來自全球4000萬忠實用户的數據,用以優化營銷投資方案和改善貨架空間分配及利用率,該項目為其帶來了125萬美元的利潤,以及超過1.25億美元的年收入增長。 第三步:達成數字化轉型成果 數字化轉型的諸多努力最終要落到可持續的數字化商業模式,以及能支持該商業模式成功運行的運營模式上。 在“數字中國”的大潮中,數字化轉型已成為每個企業的當務之急。借力數字化打造和提升競爭力,企業將在數字時代迸發出更大的活力。 埃森哲數字化轉型方法論,提出了5大關鍵行動: 1、制定面向未來的數字化戰略。 2、數字生態建設,實現全面業務升級。 3、打通研發、產品、用户,實現智能創造價值。 4、產品服務智能化升級,打造全生命週期用户差異化服務。 5、建立高韌性、高擴展性和敏捷性組織,支持業務發展和調整。 03 結語 企業數字化轉型,是一項長期持久的戰略舉措,需要企業具備足夠的重視度,配備相應的資源作為支撐,並且要有變革的決心和魄力。 從事企業數字化轉型的IT同行,也要具備業務洞察力、深度思考的能力,不要盲目追捧層出不窮的新概念。任何的方法論從提出,到企業進行消化,再到落地,都要經歷3到5年,甚至更長的時間。 ERP也好,中台也罷,或是低代碼,都要結合企業當前的情況進行深入研究。一昧迷信方法論,生搬硬套別人的解決方案,只有死路一條。 作者| Mr.K   整理| Emma 來源| 技術領導力(ID:jishulingdaoli) 作者簡介:Mr.K,企業數字化轉型觀察員、知名電商公司技術老K級人物。文出過暢銷書,武做過CTO,若非生活所迫,誰願一身才華。 免責聲明:本文內容由21ic獲得授權後發佈,版權歸原作者所有,本平台僅提供信息存儲服務。文章僅代表作者個人觀點,不代表本平台立場,如有問題,請聯繫我們,謝謝!

    程序員小灰 中台 ERP

  • 安徽省,出過哪些牛人?

    熟悉小灰的朋友們都知道,小灰很喜歡去旅遊。因為旅遊不止可以欣賞到當地的風景,也可以瞭解一個地方的歷史和文化。 前一段時間,小灰去了一趟安徽,先後遊覽了黃山、西遞宏村、呈坎村、合肥市,總共歷時十天,累並快樂着。 安徽這片土地,曾在春秋戰國時期歸於楚國,也曾在三國時期分屬吳魏。千百年來,這裏誕生過不少影響歷史進程的偉大人物,小灰希望把他們介紹給大家,讓大家更瞭解歷史,更瞭解安徽。 本文所介紹的人物,按照時間順序來排列,截止到近代。 1. 管仲 管仲,生於公元前723年,安徽省潁上縣人,春秋時期齊國經濟學家和政治家,也是法家代表人物,被後人稱為“管子”。管仲輔佐齊桓公成為春秋五霸之首。 2. 老子 老子(是三聲不是輕聲),真名李耳,生於公元前571年,春秋時期陳國(位於安徽省渦陽)人,道家學派創始人,其著作《道德經》流傳後世。 3. 莊子 莊子,名周,生於公元前369年,戰國時期宋國蒙(位於安徽蒙城縣)人,道家代表人物,著有《逍遙遊》、《齊物論》、《養生主》等,被後人收錄於《莊子》一書。 4. 劉安 劉安,公元前176年生於淮南國壽春縣(今安徽省淮南市壽縣),漢高祖劉邦之孫,西漢文學家、思想家、美食家。劉安被封為淮南王,曾招攬眾多有識之士寫成當時的百科全書《淮南子》,同時也是豆腐的發明者。 5. 曹操 曹操,生於公元155年,沛國譙縣(今安徽省亳州)人,東漢末年統一中國北方地區建立魏國,死後被追封為魏武帝。 6. 周瑜 周瑜,生於公元175年,廬江舒城(今安徽省舒城)人,東漢末年名將和顏值擔當,於赤壁擊敗曹操軍隊。 7. 朱温 朱温,生於公元852年,宋州碭山(今安徽省碭山縣)人。唐朝末年,朱温參與黃巢的農民起義軍,後歸附唐軍,鎮壓黃巢起義軍,被唐僖宗賜名“全忠”。 隨後朱温勢力逐漸壯大,進而控制朝廷,殺死唐昭宗,逼迫唐哀帝禪讓位(真夠忠誠的),建立後梁。 8. 包拯 包拯,生於公元999年,廬州合肥(今安徽省合肥東)人,北宋名臣,任職的最高官位是樞密副使(從二品)。包拯的形象也出現在清代小説《三俠五義》當中,被後人所神化,啊不,黑化了。 9.朱元璋 朱元璋,生於公元1328年,安徽鳳陽人,年輕時追隨郭子興起義,滅陳友諒、張士誠,隨後北伐推翻元朝,成為明朝開國皇帝,年號“洪武”。 10.李鴻章 李鴻章,生於公元1823年,安徽合肥人。李鴻章曾追隨曾國藩,組建淮軍,鎮壓太平天國和捻軍起義,因戰功升至直隸總督。李鴻章是洋務運動的重要領導人,也是北洋水師的組建者。 李鴻章先後參與簽訂了《馬關條約》《辛丑條約》等30多個條約,使他成為後世譭譽參半的歷史人物。 以上列出的10個人,是對中國古代和近代歷史影響最大的10位安徽人。當然,在安徽這片人傑地靈的土地上,著名人物遠遠不止這些,還包括左慈、華佗、曹仁、郭子興、李善長、常遇春、胡宗憲、年羹堯、胡雪巖、丁汝昌......由於篇幅有限,小灰就不詳細介紹了。 大家最欣賞的是哪一個人物呢?歡迎留言説出你的看法。 免責聲明:本文內容由21ic獲得授權後發佈,版權歸原作者所有,本平台僅提供信息存儲服務。文章僅代表作者個人觀點,不代表本平台立場,如有問題,請聯繫我們,謝謝!

    程序員小灰 安徽 李鴻章 管仲

  • 線程的故事:我的3位母親成就了優秀的我!

    作者 | 王磊 來源 | Java中文社羣  聲明:本故事純屬虛構,如果雷同那就是真事了! 大家好,我是線程,我的英文名叫 Thread,別看我現在風光無限,好像人盡皆知的樣子,然而我的身世卻悲慘離奇。 我出身在一個小山村,那是一個與世隔絕的世外桃源,然而年紀輕輕的我,卻展現出了與眾不同的性格。比如:當身邊的同齡人還在沉浸於玩泥巴的喜悦時,我就開始思考如何避免下雨天對出行造成的阻礙?當身邊的同齡人還在沉浸於夕陽下的奔跑時,我已經開始思考為什麼太陽會東昇西落?而我們人類又為什麼會生存在地球上?於此可見一斑。 當時的我在所有人眼裏就是一個“怪人”,村裏面的阿貓、阿狗走路都要躲着我。但我的母親懂我,她知道這個小夥子器宇不凡、骨骼驚奇,必是練武奇才,將來保護宇宙的重任和維護世界和平的重任可能要交付與我這個神童身上了,於是在我剛滿 3 歲那天,母親就把我過繼給了她的一位遠房親戚了。 首位母親:繼承Thread 接下來我要把我的出生過程演示給你看,這也是我的第一段人生經歷。 創建方式一 線程最原始的創建方式,只需要繼承 Thread 類,重寫 run() 方法即可,實現代碼如下: // 創建方式 1:繼承 Thread class MyThread extends Thread { @Override public void run() { System.out.println("你好,線程~"); } } // 測試 public class ThreadExample { public static void main(String[] args) { // 創建線程 Thread thread = new MyThread(); // 啓動線程 thread.start(); } } 變種方法 以上創建線程的方式略顯繁瑣,我們也可以使用匿名對象的方式,在創建 Thread 類的時候就直接重寫 run() 方法,實現代碼如下: // 變種 1:匿名方式創建線程 Thread t1 = new Thread() { @Override public void run() { System.out.println("線程變種"); } }; // 啓動線程 t1.start(); 繼承Thread的缺點 Java 語言的設計是單繼承,所以當繼承了 Thread 之後,就不能再繼承其他類了。 也就是説,如果我一直呆在親生母親(extends Thread)的身邊,那麼就得不到好的教育,所以長大之後也註定會普普通通,這可能就是母親把我過繼給遠房親戚的原因吧。 第二位母親:實現Runnable 在 Java 語言中,雖然不能實現多繼承,但可以實現多接口,所以我在第二位母親家,過得也算如魚得水。 創建方式二 和繼承 Thread 類差不多,實現 Runnable 接口也是重寫 run() 方法,具體實現代碼如下: public class ThreadExample2 { // 創建方式 2:實現 Runnable 接口 static class MyThread implements Runnable { @Override public void run() { System.out.println("你好,線程~"); } } // 代碼測試 public static void main(String[] args) { // 創建 Runnable 子類 MyThread myThread = new MyThread(); // 創建線程 Thread thread = new Thread(myThread); // 啓動線程 thread.start(); } } 變種方法1:匿名Runnable 以上實現 Runnable 的接口有更簡單的實現方法,我們可以使用匿名 Runnable 來創建一個線程,如下代碼所示: // 變種 1:匿名 Runnable 方式 Thread t2 = new Thread(new Runnable() { @Override public void run() { System.out.println("我是線程變種方法~"); } }); // 啓動線程 t2.start(); 變種方法2:Lambda創建Runnable 在 JDK 8 之後,我們可以使用 Lambda 表達式來操作代碼了,所以對於創建匿名 Runnable 類,我們也有了更簡單的實現方法,如下代碼所示: // 變種 2:使用 Lambda 匿名 Runnable 方式 Thread t3 = new Thread(() -> { System.out.println("我是變種 2~"); }); // 啓動線程 t3.start(); 注意:以上實現代碼只支持 JDK 1.8+ 版本。 第三位母親:村裏的首富 雖然我的前兩位母親對我都很好,但對於我這樣一個氣宇軒揚、骨骼驚奇將來要拯救宇宙和維護世界和平的少年來説,只在國內混未免侷限性太大,所以我一直想去大洋彼岸追尋自己的夢想,然而以「前兩位」母親的財力不足以支撐我這樣做。 然而我的第二個家庭和村裏的首富一家是至交,得知我的志向之後,他們一家願意傾囊相授,舉一家之力幫我去大洋彼岸追尋我的夢想。於是在感激之餘,我的第二位母親讓我當場認下首富一家為我的乾爹、乾媽。就這樣,我就有了第三位母親了。 創建方式三 前兩種創建方式雖然不錯,但都不能接收線程執行之後的返回值,於是在 JDK 1.5 之後就加入了 Callable 和 Futrue,用於接收線程執行之後的返回值,具體的實現代碼如下: import java.util.Random; import java.util.concurrent.Callable; import java.util.concurrent.ExecutionException; import java.util.concurrent.FutureTask; /** * 線程創建示例 3 */ public class CreateThreadExample3 { // 創建方式 3:實現 Callable 接口 static class MyCallable implements Callable<Integer> { @Override public Integer call() throws Exception { int num = new Random().nextInt(10); System.out.println("生成隨機數:" + num); return num; } } // 代碼測試 public static void main(String[] args) throws ExecutionException, InterruptedException { // 創建 Callable 子對象 MyCallable callable = new MyCallable(); // 使用 FutureTask 配合 Callable 子對象得到執行結果 FutureTaskfutureTask = new FutureTask<>(callable); // 創建線程 Thread thread = new Thread(futureTask); // 啓動線程 thread.start(); // 得到線程執行的結果 int result = futureTask.get(); System.out.println("主線程中拿到子線程執行結果:" + result); } } 使用 Callable 配合 FutrueTask 可以正確拿到線程執行之後的返回值。而我的故事也在這裏結束了,我最終不負三位母親所望,雖不能拯救宇宙和維護世界和平,但卻也能在程序界作出自己的一些貢獻,這就是我和我三位母親的故事。 總結 本文使用第一人稱“我”(Thread)的視角講了線程創建的三種方式,第一種是繼承 Thread,但因為 Java 語言不允許多繼承,所以當繼承了 Thread 之後就不能繼承其他類了,於是就有了第二種方式實現 Runnable 接口的方式。然而前兩種實現雖然可以創建線程,但不能接收線程執行之後的返回值,於是就有了第三種實現 Callable,通過它我們可以取得線程執行之後的返回值。 免責聲明:本文內容由21ic獲得授權後發佈,版權歸原作者所有,本平台僅提供信息存儲服務。文章僅代表作者個人觀點,不代表本平台立場,如有問題,請聯繫我們,謝謝!

    架構師社區 線程 Java Thread

  • 一個技術總監的忠告

    這篇文章我們繼續説架構師大劉的故事: 老田升職了,年薪漲到了百萬級別! 這是大劉在加班搞技術攻堅的時候,聽別的同事聊了那麼一嘴。 大劉心裏不是滋味兒。老田和大劉其實在這家公司之前就是同事了,老田能到這家公司,説起來還是大劉推薦的。 但是,在公司的這幾年,老田越來越受領導賞識,到如今,晉升成功,赫然成了大劉的上司。大劉百思不得其解。 大劉和老田本身在前家公司都是高級程序員,前後腳跳槽到了現在這家公司。 大劉來的早,成了架構師。老田呢,技術本就不如大劉,被大劉拉來後,先是當了個高級工程師,只是為了避嫌,沒跟大劉一個團隊。 後來,老田被那時候的 Leader 賞識,做了帶項目的組長,再後來,就是現在成功的晉升總監了。而大劉,好幾年了卻依然在架構師這崗位原地踏步,動彈不得。 大劉陷入了濃濃的迷茫,他自問自己工作態度毫無問題,做事情也兢兢業業。公司的技術攻關,經常也是大劉牽頭搞定。公司的技術培訓,作為架構師的大劉儼然是一個非常權威的大牛講師。 就算是老田,也需要時不時去找大劉請教一些技術難題和技術方向。可是,即使這樣,在公司技術領域造詣很深的大劉,卻依然沒有獲得進身之階,被老田壓了一頭。 大劉沒忍住,找了個不忙的日子,拉着老田去了個小飯館,在飯桌上,大劉就説起了他自己的尷尬處境以及對老田升職加薪的不解。 老田對大劉並沒有藏着掖着,在飯桌上,他和大劉坦誠溝通了他的經驗,並列出了他認為他可以升職加薪的一些非常突出的能力。 二人酒足飯飽,大劉回到家後,仔細琢磨深究,他總結了以下幾點。 1. 儘量努力的多去閲讀別人的代碼,越多越好 這點大劉開始並沒當回事,可是在和老田溝通的過程中,大劉發現,老田理解的閲讀別人的代碼和他理解的閲讀代碼是兩回事。 大劉閲讀代碼,特別喜歡看那些開源的好代碼。跟着文檔品讀那些開源的優秀代碼的卓越之處,每當看到妙處,大劉都覺得學到了新東西,感覺自己技術進步了許多。 但是,當大劉閲讀自己公司的各種代碼的時候,大劉是相當沒有耐心的。他覺得別人代碼寫的太次了,他把這些代碼統統成為“屎山”。 而老田恰恰相反。老實説,老田對市面上各種開源框架的瞭解水平,對各種中間件的內部原理理解都是遠遠不如大劉的,經常還需要諮詢大劉。 但是,對於公司的各項目代碼,老田卻是瞭如指掌,對各項目中的那些代碼和問題都是有十分深入的瞭解。 那麼最終升職加薪不是大劉,這是為什麼? 二人聊完之後,大劉終於明白了。 首先,公司除了需要大劉的技術能力,更需要的是作為技術專家解決公司實際問題的能力。 由於大劉牴觸閲讀公司很多項目的代碼,所以,往往大劉的某些技術方案在落地的時候會出現脱節。有時候,又由於對項目代碼的不理解,甚至沒有給出有效的解決方案。 而老田,由於對公司項目代碼瞭解的很深入,雖然技術能力或者説知識面不如大劉,但是卻總是能給出最合理的解決方案來。 長此以往,老田反而比大劉更展示出了一位高級技術人員應該具有的能力。 很多程序員和大劉其實是一樣的,他們不喜歡自己公司的很多代碼,認為這些代碼質量極差,文檔也非常欠缺,對自己的成長幫助不大。 其實這個觀念其實是很有問題的。 對這些所謂“屎山”的代碼,你如果全都讀進去,研究下去,你起碼會有兩個好處: 你能具體知道代碼爛在什麼地方,那麼以後你的代碼就不會出現同樣的問題——由於你知道了爛代碼爛在哪裏,你一定能寫出更好的代碼,從而讓那些屎山的代碼逐漸會被自己寫的好代碼所替代。這樣一比較,你的專業能力會顯得非常突出,讓更多的人認可你這位架構師的能力。 你對公司這些代碼讀的越多,掌握的越多,你越不可替代——對公司這些代碼讀的越通透,你越能更快速輕鬆地把控這些代碼,讓以後對這些代碼的變革變得更容易。而輕鬆修改、革新這些代碼的能力,就會變成你在這家公司不可替代性的重要因素。 所以,各種代碼,無論質量好壞,都需要能讀懂讀通,並且讀的越多越好。 能讀懂讀通任何質量的代碼,才是真正的掌握了閲讀代碼的能力。讀的越多,則能識別代碼質量的能力就越強,將來自己就越能寫出更好質量的代碼。 2. 能準確判斷項目的發展方向 大劉和老田談的時候,讓大劉印象最深刻的就是,老田對項目發展狀態的精準判斷。 三年前,倆人一起搞了個供公司所有業務項目用的監控系統,目的是解決公司項目錯誤無法及時發現和處理的問題。 當時,這套監控系統公司要的急,大家匆匆設計了一版,就趕緊趕鴨子上架的做了一版。 技術方案也沒花太多心思,怎麼快怎麼來。搞完之後,大劉覺得這項目以後也就這樣了,公司內部項目,既沒有發展,也沒有什麼前景。 可是,如今和老田溝通後,大劉才吃驚的發現,老田居然一直跟着這個項目,並對這項目進行了無數次總結分析和優化。 隨着不斷地改進,這套項目竟然發展出來了一套非常完備的 APM 系統,使用體驗非常不錯。公司的商務給客户出解決方案的時候,經常也會連帶着把這套監控系統包含到解決方案裏。客户的反饋也很好,為公司拿下了更多的訂單。 而大劉自己呢,為公司的核心繫統設計了一套底層的服務調度編排框架,公司很多系統的底層都依賴於這套框架。 雖然這套框架大劉自己認為寫的很棒,但是由於部署複雜,對應的一些輔助工具鏈也由於大劉的忽視,沒有及時開發出來。導致後續的新項目,大家寧肯用一些開源框架自己改進,也不再使用大劉的這套框架。 分析起來,其實這也算是大劉和老田對各自項目的發展判斷能力的差距導致的。 老田根據用户反饋和市場行情,他感覺監控系統本身應該是有前途的。並在調研了市面上競對產品的基礎上,讓這套監控系統迸發出來了絢爛的色彩。 而大劉,高開低走,寫出來一個好框架,但是由於對框架的預期判斷錯誤,加上對用户反饋重視不夠,最終導致本來應該非常出彩的框架就此沉淪了下去。 3. 去主動管理會議 作為公司比較重要的技術專家,大量的會議是免不了的。 大劉對此非常煩惱,經常因為這些冗長的會議,耽誤了許多手頭的工作。 特別是,大劉作為架構師,需要大塊連續的時間去思考技術難題,解決系統問題,以及考慮新項目的架構設計。但是頻繁的會議,把大劉的時間攪和的支離破碎。 對於這個問題,大劉在飯桌上請教了老田。老田説,他也面對了這些問題,好在他通過一些自己的方法,很大程度緩解了這些問題。 老田做了如下幾個事情: 老田對第二天的會議提前和參會各方溝通,開會時間儘量協調到一起,這樣老田能騰出一整塊兒時間,把當日所有可能的會議都集中開完。後續老田就會有連續的時間去深度工作了。 老田會在開會前一天,把會議內容和可能出現的問題都預先做功課。一方面是防止會議開着開着跑題;二是萬一出現爭議問題,老田可以列舉出來事先準備的技術方案,這樣也能加快會議進度。 還有,對於一些不那麼重要的會議,老田一定會態度堅決的避開或者指派別人蔘加。 4. 版本控制工具的熟練應用 這個問題是老田主動和大劉提出來的。 老田發現,對於版本工具使用不當,會耽誤開發人員很多時間。而版本控制工具,即使一些工作多年的程序員,往往也經常會使用不當。 這些不當的使用,會造成許多問題。比如,各種各樣的代碼衝突、版本重疊,莫名其妙的代碼丟失。 對此,老田每次負責一個新項目,都會嚴格指定版本工具的使用規範,會花時間對開發人員統一培訓版本工具的使用。同時,也會把各種技巧、注意事項、常用命令整理好,放在內部的共享文檔中。 老田的這些舉措,在實踐中,大大改善了版本控制工具不當使用造成的問題。 有一個項目組在規範使用之後,竟然比之前的開發速度快了三分之一。可想而知,這個問題有多嚴重了。 5. 不要把解決方案複雜化 老田和大劉談了談關於技術和技術落地之間存在的問題。 老田和大劉都發現有些程序員特別喜歡炫技,這些炫技某些時候會導致整個系統複雜化,最終產出反而不盡如人意。 老田舉了個例子,比如,一套內部使用的資產管理系統,中間有一個需要調用公司其他項目接口的小功能,這種簡單的東西交給了一個比較年輕的程序員。 結果這個程序員又是考慮對方接口不穩定的情況,又是考慮這個功能會有使用過度頻繁的情況,還使用了緩存去儲存一些狀態,防止頻繁調用數據庫。 對於這種情況,從純技術角度,當然會鼓勵人們想的越全面越好。但是,在實際落地的時候,你要明白這只是一個公司內部使用的小項目,沒必要為了各種概率很低的風險,把明明很小的一個功能給做的很複雜。 針對這種問題,就需要技術 Leader 及早發現、介入,防止出現過度設計、過度開發。 6. 把任務安排的井井有條 老田其實和大劉一樣,每天雜事兒很多,每天的任務也很多。大家對這些任務的管理能力自然就有高有低。 老田對於任務緊急程度的判斷都是經過深思熟慮、實際分析過的,任務之間的先後順序,也和任務交付人認真溝通過。對一些根本沒必要的任務,老田會態度堅決的對這些任務説 No。 大劉自我總結,他這方面做的不好。首先,他安排任務容易被任務交付人的情緒影響,對方催的急,他就優先安排。其次,任何任務大劉都沒有拒絕過,頂多是排期靠後。最後,大劉沒有考慮任務和任務之間的關係,有些任務之間是關聯的,完全可以融合一起搞定,大劉卻沒有思考,從而割裂開安排,這也是很大的問題。 比如上次,大劉接到兩個任務:1、去掉 VMware;2、MQ 版本升級。 這兩個任務都需要業務系統停服才能幹,大劉當時也沒在意,兩個任務放在兩天,連續兩天停服,雖説每天停的時間不長吧…… 這倆任務完全可以放在一起,利用一次停服集中解決。這樣對用户影響更小,業務部門也不會那麼不滿。 7. 不要死板的寫代碼 很多程序員知識面很寬,基本功也非常紮實。但是,有一種能力,是學校教不出來、面試也不容易看出來的,就是代碼能力。 所謂的代碼能力,有的是指寫代碼不出 Bug 的能力,有的是指算法落地能力……但這裏想説的,是不寫死板的呆代碼的能力。 這是什麼意思呢? 我們都知道,程序員少不了要維護老項目。在維護項目的時候,我們面對各種不斷的新需求,經常要去修改代碼。 修改代碼是個很危險的事情,因為我們修改的代碼往往會和別的功能耦合住。改了一點代碼,結果影響一大片功能的情況經常出現。最虐心的是,這種連帶影響可能不會馬上出現,不知道哪天就突然冒出來折騰一把。 如果改代碼經常出問題,這誰扛得住啊!別説你自己的技術話語權了,也別説在職場脱穎而出了,工作能不能保得住都不好説。 所以,對於修改代碼的事情,我們需要學會的是不要寫呆代碼。再説的直白點就是,你不能寫完代碼運行下沒問題就覺得正常了,你在寫代碼之前需要好好思考。 這種思考,既不是什麼搞設計模式松耦合,也不是搞功能切分獨立成塊。這種思考本質是需要你寫代碼前去理解業務,去真正明白業務在實際是怎麼運作的。 簡單説兩個例子: 7.1. 修改完代碼後,用户會怎麼使用你現在修改的功能? 比如,你修改了註冊功能,可以兼容第三方登錄。那麼,可能有的老用户會重新註冊一個賬號,以方便第三方登錄。那你對這種情況,其實該做的是綁定,而不是讓用户重新註冊個新賬號。 這種疏漏,等到上線之後才發現就晚了。這不能完全依賴產品經理,作為一個技術人員本來就應該對自己的功能做通盤的考慮,這才是真正的負責。 7.2. 你現在修改的功能,會不會由於運營需要,會換成你完全沒想過的用法? 比如,你搞一個用户充值功能。本來你只是想着用户遊戲內購直接充值即可。但是,在實際上線後,有時候運營為了方便 vip 客户或者為了和第三方渠道互換資源,也會使用這個充值功能。 運營大批量的連續充值,並且這些充值轉換成系統中的貨幣,就像遊戲中的元寶,就有可能超出 Java 中的整數上限,從而造成問題。如果你提前知道用户、運營人員都是怎麼使用這個功能的,你就會把數據類型修改成 Long 了。 類似的例子有很多,老田還要繼續説下去的時候,大劉給他打斷了,“扎心了,你説這些坑我沒少掉進去。” 後記 通過和老田溝通,大劉知道自己的問題出在哪了。他明白了,技術只是技術人員的基礎,在實際工作中想脱穎而出,除了要有過硬的技術,還需要你的態度、你的各種軟實力,需要你把技術轉化為實際生產力的能力。 免責聲明:本文內容由21ic獲得授權後發佈,版權歸原作者所有,本平台僅提供信息存儲服務。文章僅代表作者個人觀點,不代表本平台立場,如有問題,請聯繫我們,謝謝!

    架構師社區 架構師 技術總監

  • Microchip發佈可信平台設計套件(TPDS)加速嵌入式安全部署,向第三方開放生態系統

    Microchip發佈可信平台設計套件(TPDS)加速嵌入式安全部署,向第三方開放生態系統

    2019年,Microchip Technology Inc.(美國微芯科技公司)發佈了用於CryptoAuthentication™系列的Trust Platform(可信平台),這是業界首個基於硬件的安全元件預配置解決方案,旨在幫助各種規模的企業以簡便方式實現安全認證。Microchip今日宣佈推出可信平台設計套件(TPDS)的最新增強版,進一步豐富產品陣容。TPDS是一款專門用於設備配置和加入Microchip嵌入式安全預配置服務的軟件平台。 TPDS第2版(v2)軟件使Microchip合作伙伴能夠將用例添加到豐富的安全解決方案入網(onboarding)生態系統,進一步擴大了開發者在部署一流安全方面業已非常廣泛的選擇。TPDS第2版現在還支持其他安全解決方案,如首款用於汽車市場的加密配套設備TA100。 簡化開發 一個有經驗的固件工程師可能需要幾個月的時間來確定一個應用的威脅模型,以及開發一個包括安全認證、安全啓動、IP保護等所有必要措施的安全用例。其中涉及的兩個主要挑戰在於配置設備的安全邊界和預配置密鑰,包括私鑰以及對稱密鑰和其他形式的密鑰數據。 TPDS軟件通過提供預先定義的用例來解決最常見的市場要求,從而簡化了開發過程。它可與三個可信平台流程中的兩個一起使用——Trust&GO和TrustFLEX。這些方案使新的安全項目能夠在幾分鐘內通過TPDS v2建立原型,同時根據客户的部署規模、用例要求和所需要的定製程度提供選擇: · Trust&GO——設備是預先定義和預先配置的現貨,用於基於TLS和LoRaWAN網絡的安全雲認證,最小可訂購量(MOQ)僅為10台起訂。 · TrustFLEX——客户可通過默認的通用證書或專用證書(自定義PKI)來使用此方案的預配置設備,同時支持比Trust&GO方案更廣泛的預定義使用案例。 為了滿足最苛刻的使用情況,Microchip的TrustCUSTOM系列讓客户可以自由地完全定義安全認證配置和完全定製安全密鑰存儲。 藉助完全集成的配置入網(onboarding)流程,TPDS v2軟件允許客户選擇安全解決方案,驗證用例,製作原型,然後開始安全預配置過程,所有這些都只需幾個簡單步驟。 Microchip安全產品業務部副總裁Nuri Dagdeviren表示:“我們的TPDS v2軟件通過將安全最佳實踐融入直觀和簡化的流程,使開發人員能夠輕鬆遵守現有標準和即將出台的嵌入式系統安全法規。我們將繼續通過可靠的硬件和安全解決方案,幫助客户加快產品上市並贏得長期業務。TPDS還將支持Microchip安全解決方案在安全元件之外的入網(onboarding)和預配置服務。” 第三方集成 TPDS v2的最大優勢之一是,它使第三方合作伙伴能夠添加自有用例,豐富了客户對安全元件入網和安全功能的選擇。Microchip合作伙伴之一EBV Elektronik(安富利集團)使TPDS v2用户能夠通過ATECC608B TrustFlex配置,使用EBV-IoT“安全盾牌”評估工具包快速、安全地連接到安富利IoTConnect雲。欲瞭解更多信息請點擊這裏。 EBV Elektronik技術開發副總裁Antonio Fernandez表示:“我們與Microchip有着緊密的合作關係,非常高興能夠成為可信平台設計套件v2計劃的一部分,使所有客户在芯片和雲端都能獲得可擴展的安全性。採用最佳實踐是實現我們為所有客户提供最佳安全平台共同目標的重要一步。我們相信,TPDS的增強功能提供了最簡單、最經濟的方式,讓我們得以繼續位於行業前列,助力客户部署一流的解決方案。” TPDS v2軟件工作原理 可信平台設計套件V2使用户能夠: · 通過培訓視頻和適用於各類用例的交互式應用筆記,實現安全入網; · 根據選定用例開發應用程序,最終確定安全解決方案的配置,執行祕密密鑰交換; · 採購驗證樣本並開始生產。 開發工具 可信平台設計套件支持Windows®和macOS®環境。TA100配置器僅適用於Windows平台。 供貨與定價 Microchip的開源可信平台設計套件(TPDS)可在Microchip網站免費下載,用於Trust&GO和TrustFLEX流程。網站還提供培訓視頻、互動應用筆記、C代碼和其他項目支持。用於TPDS的TrustCUSTOM軟件擴展可在簽署NDA的條件下提供,可通過Microchip直銷網站購買,單價為20美元。 如需瞭解更多信息,請聯繫 Microchip 銷售代表、全球授權分銷商或訪問Microchip網站。

    Microchip Microchip 嵌入式 TPDS

  • 魔幻!2021年,6種將死的編程語言?

    隨着編程語言的更新迭代,編程界語言排行榜又要面臨一次全新的洗牌,六大編程語言將要黃了!此消息一出,令眾多程序員心碎!那麼這將“亡”的六大語言中有你所擅長的嗎?   壹 dashuju Perl 曾幾何時,幾乎每個人都在使用Perl語言編程。但是那些經常使用的人慢慢地發現,關於這個Perl語言似乎總是有點不對勁。至少我知道有這麼個叫做“piecemeal”的編程語言,它的創造者似乎就只是將這個功能堆在另一個功能上面而已,並沒有好好考慮將它們結合在一起。 事實上,甚至是它的創造者也不得不承認這種編程語言是有問題的。經過完整地改造之後,現在的開發工作開始傾向於使用Perl6,這個大概是在2000年的時候。至於Perl?儼然已經銷聲匿跡了!所以完全沒有必要去學習它了。順便説一句,下面這個“Goodbye World”就是用Perl寫的: #!/usr/bin/perlprint “Content-type: text/html\n\n”;print “Goodbye, world!\n”; 上面這個例子會出來一個網頁。現在的Perl,由於可以作為CGI腳本語言,所以使用的最廣泛的是在生成web頁面上。但是為了適應時代的變化,我們最好還是將Perl語言“棄之如敝履”。  貳 dashuju Haskell 據説,Haskell 即將在今年進行重大更新。有很多巨頭公司和項目(Facebook、GitHub 等)曾經使用 Haskell 開發過一些重要項目。不過,Haskell 在 RedMonk 語言排行榜上的表現一直都很平淡,這表明沒有更多的開發者在關注這門語言。它要死了,還是已經死了? 另外一種聲音: 在以前的Haskell 用户調查 中,我們可以看到下面五大亮點: 1.Haskell 社區已經開始更加多樣化和專注於項目,雖然 Haskell 一直以來以“僅限科學家”著稱。 2.Haskell 不僅被用於混合語言項目,還被用於構建完全用 Haskell 編寫的端到端解決方案。3.Haskell 社區被認為能給用户提供許多支持。 4.Haskell 在商業環境,特別是 FinTech 中的應用日益增多,但在網絡安全和電子商務方面的應用規模仍較小。 5、在過去三年中,Haskell的工具已經有了很大的改進,Stack和Cabal等工具已有大約80%的用户使用。 對於兩種聲音你們怎麼看?  叁 dashuju Ruby 關於Ruby,可以這麼唱“十年之後,我不認識你你不屬於我……”。因為就在10年前,Ruby語言可謂是風靡一時。它出生於1995年,5年左右達到它的鼎盛時期。如果你經常使用的話,絕對會義無反顧地愛上它。但是,像我們這些學着C語言風格長大的孩子在學習Ruby時往往會覺得有點囧。 下面是用Ruby寫的“Goodbye World”: puts ‘Bye bye, Miss American Ruby! Drove my Chevy to the Levie…’puts ’2011 was the day that Ruby died, yeah…’ 下面是一個用於計算階乘的例子: def fact(n)  if n == 0    1  else    n * fact(n-1)  endendputs fact(ARGV[0].to_i) 我測試了這個例子,來計算1000的階乘。下面是結果(由於篇幅限制,中間略過了2569個數字): ruby fact.rb 100040238726007709377354370243392300…0000000 從各方面來看,Ruby都很好,幾乎是一片讚譽聲……除了Twitter。在2011年4月,Twitter宣稱他們已經將幾乎大部分的代碼都改寫過了,以便不必使用Ruby和它的web框架——Ruby on Rails,據他們所説這個平台非常之低效。不過,我想説的是,也正是那一天起,Ruby開始走下坡路,使用的人數也是越來越少。  肆 dashuju Visual Basic.NET 十年前,我應聘到一個需要重寫大量代碼的公司,名字我已經忘記了,主要工作就是將VB6轉換為Visual basic.NET。大概就只幹了一兩個月吧,我就跳槽了:真心太痛苦了。 微軟鍾愛於BASIC編程語言的擴展可以一路追溯到1991年,那時他們剛剛採購了來自Alan Cooper的一個非常酷(對於那個時候而言)的可視化編程設計。Alan Cooper初期使用的是別的編程語言,但是比爾蓋茨讓他換成BASIC語言,因為蓋茨認為那是當時最為簡單的編程語言。於是乎,大名鼎鼎的Visual Basic,就從BASIC中衍生出來——對象這一概念以及新的編程技術問世了。 後面又發生了一些很有意思的事情。Borland Delphi的創造引領者,Anders Hejlsberg也到微軟工作,並且引領創建了一個新的編程語言——C#。這種編程語言非常類似於Java語言。剛開始的學習或許有點難,但是一旦上手,你絕對會對它愛不釋手。C#很快就成為了微軟的旗艦編程語言。現在的話,在軟件行業中,有很多很多需要C#的工作崗位,不少都是高薪聘用的。 雖然針對自己的CLR運行,微軟創建了C#,但是它的工程師們另外還創建了一個蓋茨深愛的BASIC語言版本,命名為Visual Basic.NET。該編程語言借用了BASIC語言的語法,但是它的編碼方法卻與C#相似。雖然Visual Basic.NET也在發展,但是優勝劣汰總是不可避免的——大家都選擇了C#,於是Visual Basic.NET就成為了明日黃花。 下面是摘自微軟網頁上的一段Visual Basic.NET程序: ‘ Allow easy reference to the System namespace classes.Imports System‘ This module houses the application’s entry point.Public Module modmain   ‘ Main is the application’s entry point.   Sub Main()     ‘ Write text to the console.     Console.WriteLine (“Hello World using Visual Basic!”)   End SubEnd Module (這裏的“Hello World”也可以替換成“Goodbye World”,這個沒關係。  伍 dashuju Adobe Flash和AIR 從技術上講,這些都是平台,而非編程語言。我之所以將它們包含進來是因為如果你想要使用它們,就必須安裝Adobe自己的ECMAScript版本,即ActionScript。ActionScript是JavaScript(當前最流行的編程語言之一,因為它能用於所有的瀏覽器)的一個近親。ActionScript在ECMAScript(這是JavaScript實現標準的官方名稱)中增加了一些細節;但是除了Adobe Flash,其他地方几乎沒有ActionScript的用武之地。 你使用Flash不?喬布斯非常討厭它,並且也不允許iPhone使用它。然後隨着iPhone(以及隨後的iPad)的逐漸普及,Web開發人員不得不創建不必依賴於Flash的網站。那些以ActionScript為生的開發人員也不得不紛紛下崗。(我曾經看到過一個Flash開發人員指責另一個JavaScript開發人員毀了他的職業生涯。) Adobe也曾試圖通過AIR以求得其編程平台的一線生機,於是配建了一個用於構建AIR app的工具,稱為Flex。至於AIR,許多人都説,這是一場災難。不過我們目前也不知道為什麼Adobe會推出AIR,可能是想用AIR取代Flash?也可能是想要AIR和Flash相親相愛共同發展? 記得有一段時間,得益於Twitter平台——TweetDeck(要求用户在電腦上安裝AIR運行時)的使用,AIR很是紅火了一陣子。那時大概有數以百萬計的pc AIR應用被開發出來,只是後來Twitter在2011年買了TweetDeck之後,又改寫本地代碼取代了AIR。於是乎,AIR的輝煌就到此為止。 隨着Flash和AIR的逐漸逝去,Adobe的ActionScript也開始向世界吻別。下面是一些用ActionScript寫的代碼示例。 package {import flash.display.*;import flash.text.*;public class HelloWorld extends Sprite {   private var greeting:TextField = new TextField();public function HelloWorld() {     greeting.text = “Hello World!”;     greeting.x = 100;     greeting.y = 100;     addChild(greeting);   } }} (你可能會發現這與JavaScript非常相似,都使用var、function和new,並且也使用小數點來訪問成員變量。)  陸 dashuju Delphi’s Object Pascal 首先我得向我曾經的好夥伴Delphi表示歉意,因為我不得不公佈Object Pascal的“死訊”。well,Delphi(用於發Object Pascal的工具)歷經變遷之後,依然苟延殘喘着(它起源於Borland公司,現在抱着Embarcadero公司的大腿)。 早先Delphi和它的Object Pascal語言確實給我們提供了一個良好的工作環境:雖然有點囉嗦,但是編譯器很快,而且相比Visual Basic(這裏指的是pre-Visual Basic.NET,1995年左右),創建Windows程序更容易。 但是它的優勢並沒有持續下去。也很難説是什麼原因,因為這個平台真心是不錯的。就在這時,Borland公司開始在其Delphi的產品線上支持C#和C++。發展到後來,Borland公司甚至直接將Delphi賣給了Embarcadero公司,然後Embarcadero公司繼續使用Delphi開發產品。話説,它做得相當不錯,但是重點再也不是Pascal了。當然,你依然可以用Pascal編程,但是幾乎沒人走這條路了。事實上,我們可以使用Delphi建立許多不同的平台,包括iOS、Android,以及Linux操作系統。 但是,如果你去Embarcadero公司的網站看看,你會發現他們主要是在促進Delphi’s C++ 的支持。因此,換言之就是,Object Pascal已然逝去了。寫到這裏,我不禁悲從心來,因為我花了很多很多時間來學習Pascal語言,特別是Delphi’s Object Pascal。但是沒辦法,現實就是如此殘酷,不轉行就只能餓死。 下面請看Object Pascal的代碼: program HelloWorld;begin    writeln(‘You say goodbye.’) 譯者注:以上觀點僅代表作者個人觀點,請文明禮貌按秩序吐槽。 譯文鏈接://www.codeceo.com/article/5-die-programming-language.html英文原文:5 Programming Languages Marked for Death翻譯作者:碼農網 – 小峯 免責聲明:本文內容由21ic獲得授權後發佈,版權歸原作者所有,本平台僅提供信息存儲服務。文章僅代表作者個人觀點,不代表本平台立場,如有問題,請聯繫我們,謝謝!

    架構師社區 嵌入式 編程 C語言

  • 百度一 29 歲程序員因使用CURL命令“篡改數據”被判有期徒刑一年九個月

    整理 | 王曉曼 出品 | 程序人生 (ID:coder _life) 近日,中國裁判文書網公佈了一起非法控制計算機信息系統、給賭博網站“大開方便之門”的案件,涉及金額達374萬元。據案件顯示,在百度時代網絡技術(北京)有限公司擔任研發工程師的陳某,出生於1992年,利用其職務之便,超越權限,通過篡改數據、編寫腳本等方式,違規通過了735個媒體網站賬號加入“百度聯盟”的申請,致使公司374萬元廣告分成遭到損害。 經查,陳某在2017年9月至2018年3月的半年間,以審核每個網站300元的價格,據此收受他人給予的人民幣235935.4元。 1,為“掙外快”,92年程序員被“拉下水” 根據裁判文書顯示,2015年9月16日,陳某入職百度時代網絡技術(北京)有限公司,擔任研發工程師,所在部門為展示廣告平台部的union團隊,主要負責展示廣告平台部流量端系統的開發工作,權限範圍是百度聯盟流量端系統的功能開發以及日常上線與維護。 陳某負責該系統的開發與維護工作,無權審核媒體資質,也沒有權限對媒體審核服務器計算機系統程序裏的數據進行非研發、調試和維護性需要的修改。 2017年8月,自稱劉某的男子通過微信聯繫到陳某,稱有“私活”可以“掙外快”,問其能否做快速審核(審核網站是否能有資質承接百度聯盟廣告),但被陳某拒絕了。 沒過多久,劉某從哈爾濱到了北京,在對外經貿大學附近一個飯館約陳某吃飯,説還是想做審核網站的事情,需要使用百度在職員工的權限,幫助其快速通過審核網站。 這一次,陳某動搖了。他找劉某要了9000元錢,審核每個網站300元,共審核30個。 2,程序員改當“審核員”,篡改數據違規“開綠燈” 百度公司進行網站審核的正常方式是審核部門的員工,依據聯盟業務審核標準,對百度聯盟風險防控平台待審核聯盟潛在客户進行審核。聯盟的網站需要通過兩道審核,方可上線。 正常流程是客户提交網站先過機器審核策略,機器審核策略過濾掉問題網站(如包含無ICP備案,網址打不開等情況的),將沒有觸犯機器審核策略的網站推送至人工待審列表中,最終上線需要經過人工審核。 按照流程,百度公司與任何媒體進行廣告合作,應該首先由媒體通過流量端系統進行登記網站信息,而後由公司業務審核部門員工進行審核,對符合合作標準的媒體才能通過審核,這些合作媒體後續才能通過百度系統投放線上百度接入的廣告,從而獲得百度公司的廣告分成。 但陳某就職於展示平台廣告部,工作職責不包括審核工作。 據裁判文書顯示,陳某違規登錄聯盟風控平台篡改了待審核客户的狀態,將不能通過審核的網站直接變更為審核通過狀態,從而直接上線。 陳某使用的其中一種方式是通過CURL命令調用流量端系統的媒體審核接口,另一種是通過編寫腳本批量操作的方式調用了流量端系統的媒體審核接口,從而篡改數據。 據悉,經過陳某走“綠燈”通過的網站內容,甚至涉及到賭博、彩票等業務。 3,事情敗露,陳某當場承認違規操作獲利 2018年2月27日,百度公司相關部門發現在風控平台審核媒體時,部分媒體無法進行正常審核操作。 經排查發現,這些媒體在UNION平台中是審核通過狀態,但這些媒體在風控平台和UNION平台的審核狀態不一致,可能存在人工調用審核接口使這些媒體繞過業審,有異常審核通過的情況存在; 進一步排查分析,發現疑似存在陳某在相關機器上進行了工作職責不相符合的操作,對部分沒有經過業審審核的媒體,進行了“媒體審核通過”的操作,異常審核通過的媒體有735個,分成金額3745054元。 2018年3月2日,百度公司相關部門將上述情況以電子郵件形式發送給百度時代網絡技術(北京)有限公司職業道德委員會。 公司得知此事後,於2018年3月5日指派相關工作人員找到陳某商談此事,他當場就承認了通過CURL命令調用流量端系統的媒體審核接口,以及通過編寫腳本批量操作的方式調用了流量端系統的媒體審核接口,從而篡改數據,使得部分媒體獲利的情況。 公安機關於2018年3月11日接到百度公司報案稱公司員工陳某涉嫌破壞計算機信息信息系統犯罪,後於同年4月20日將前往百度公司接受約談的被告人陳某傳喚到案。 4,法院這樣判 北京市海淀區人民法院一審認為,陳某違反國家規定,對計算機信息系統中存儲、處理的數據進行修改,後果特別嚴重,其行為已構成破壞計算機信息系統罪,應予懲處。 法院指出,被告人陳某利用其工作便利,在沒有得到單位授權,也不是基於對單位計算機信息系統進行研發、維護、調試等工作需要的情況下,而是為了謀取其個人私利,超越其工作權限,採用技術手段擅自調用媒體接口,違規使大量網站通過媒體資質審核,將待審核的數據變更為審核通過的數據,系違規修改百度時代網絡技術(北京)有限公司計算機信息系統內所存儲、處理的相應分類數據的範圍,因此該行為符合破壞計算機信息系統罪中對破壞行為的定義。 鑑於被告人陳某犯罪以後主動投案,到案後能如實供述其所犯罪行,系自首,且積極退繳全部違法所得,並賠償了所在單位因本案而支出的信息技術服務費,亦取得了所在單位的諒解,有較好的悔罪表現,故本院對其依法減輕處罰。 最終,被告人陳某以犯破壞計算機信息系統罪,被判處有期徒刑一年九個月,並沒收所有違法所得。 免責聲明:本文內容由21ic獲得授權後發佈,版權歸原作者所有,本平台僅提供信息存儲服務。文章僅代表作者個人觀點,不代表本平台立場,如有問題,請聯繫我們,謝謝!

    架構師社區 百度 程序員

  • 新東西:KubeSphere 3.1.0 GA

    2021 年 4 月 29 日,KubeSphere 開源社區激動地向大家宣佈,KubeSphere 3.1.0 正式發佈!為了幫助企業最大化資源利用效率,KubeSphere 打造了一個以 Kubernetes 為內核的雲原生分佈式操作系統,提供可插拔的開放式架構,無縫對接第三方應用,極大地降低了企業用户的使用門檻。 KubeSphere v3.1.0 主打 “延伸至邊緣側的容器混合雲”,新增了對 “邊緣計算” 場景的支持。同時在 v3.0.0 的基礎上新增了 計量計費,讓基礎設施的運營成本更清晰,並進一步優化了在 “多雲、多集羣、多團隊、多租户” 等應用場景下的使用體驗,增強了 “多集羣管理、多租户管理、可觀測性、DevOps、應用商店、微服務治理” 等特性,更進一步完善交互設計提升了用户體驗。 雲原生產業聯盟撰寫的《雲原生髮展白皮書》提到,萬物互聯時代加速了雲-邊協同的需求演進,傳統雲計算中心集中存儲、計算的模式已經無法滿足終端設備對於時效、容量、算力的需求,向邊緣下沉並通過中心進行統一交付、運維、管控,已經成為雲計算的重要發展趨勢。 面對這一發展趨勢,KubeSphere 與 KubeEdge 社區緊密合作,將 Kubernetes 從雲端擴展至邊緣,以統一的標準實現了對邊緣基礎設施的納管。通過與 KubeEdge 集成,解決了邊緣節點納管、邊緣工作負載調度和邊緣可觀測性等難題,結合 KubeSphere 已有的多集羣管理將混合多雲管理延伸至邊緣側。 並且,v3.1.0 得到了來自青雲 QingCloud 之外的更多企業與用户的貢獻和參與,無論是功能開發、功能測試、缺陷報告、需求建議、企業最佳實踐,還是提供 Bug 修復、國際化翻譯、文檔貢獻,這些來自開源社區的貢獻都為 v3.1.0 的發佈和推廣提供了極大的幫助,我們將在文末予以特別緻謝! 解讀 v3.1.0 重大更新 KubeSphere 3.1.0 增加了計量計費功能,支持集羣、企業空間的多層級與多租户在應用資源消耗的計量與統計。通過集成 KubeEdge,實現應用快速分發至邊緣節點。同時還提供了更強大的可觀測性能力,如兼容 PromQL、內置主流告警規則、可視化對接釘釘、企業微信、Slack 和 Webhook 等通知渠道。DevOps 的易用性在 3.1.0 也上了一個台階,例如內置多套常用流水線模板,支持多分支流水線和流水線複製等,關於重大更新詳情請查看文末海報。 多維度計量計費,讓 K8s 運營成本更透明 在企業運營和管理 Kubernetes 容器平台時,通常需要分析資源消耗,查看集羣及其中租户的消費賬單,洞察資源使用情況,分析基礎設施運營成本。 在 KubeSphere 3.1.0 中,可從多個維度來分析平台資源消耗: 從集羣維度,可查看每個集羣資源消耗,深入到節點中分析運行的工作負載,精準規劃每個節點中工作負載的資源使用狀況。 從企業空間維度,可查看每個企業空間資源消耗,獲取企業空間中項目、應用、工作負載的消費賬單,分析多租户環境中各個租户的資源使用是否合理。 另外,除了可以通過界面查看和導出數據,KubeSphere 計量計費平台也提供了所有操作的 API。接下來在後續的版本里,會持續加強並構築端到端完整的計量計費可運營系統。 邊緣節點管理 KubeEdge[1] 是一個開源的邊緣計算平台,它在 Kubernetes 原生的容器編排和調度能力之上,實現了 雲邊協同、計算下沉、海量邊緣設備管理、邊緣自治 等能力。但 KubeEdge 缺少雲端控制層面的支持,如果將 KubeSphere 與 KubeEdge 相結合,可以很好解決這一問題,實現應用與工作負載在雲端與邊緣節點進行統一分發與管理。 這一設想在 v3.1.0 中得以實現,KubeSphere 現已支持 KubeEdge 邊緣節點納管、KubeEdge 雲端組件的安裝部署、以及邊緣節點的日誌和監控數據採集與展示。結合 KubeEdge 的邊緣自治功能和 KubeSphere 的多雲與多集羣管理功能,可以實現雲-邊-端一體化管控,解決在海量邊、端設備上統一完成應用交付、運維、管控的需求。 強化微服務治理能力 KubeSphere 基於 Istio[2] 提供了金絲雀發佈、藍綠部署、熔斷等流量治理功能,同時還支持可視化呈現微服務之間的拓撲關係,並提供細粒度的監控數據。在分佈式鏈路追蹤方面,KubeSphere 基於 Jaeger 讓用户快速追蹤微服務之間的通訊情況,從而更易於瞭解微服務的請求延遲、性能瓶頸、序列化和並行調用等。 KubeSphere 3.1.0 對微服務治理功能進行了強化,將 Istio 升級到了 1.6.10,支持圖形化流量方向檢測,圖像化方式顯示應用流量的流入/流出。同時還支持對 Nginx Ingress Gateway 進行監控,新增 Nginx Ingress Controller 的監控指標。 多雲與多集羣管理 雖然 KubeSphere 3.0.0 帶來的多雲與多集羣管理提供了面向多個 Kubernetes 集羣的中央控制面板,實現了應用跨雲和跨集羣的部署與運維,但 member 集羣管理服務依賴 Redis、OpenLDAP、Prometheus 等組件,不適合輕量化部署。KubeSphere 3.1.0 移除了這些依賴組件,使 member 集羣管理服務更加輕量化,並重構了集羣控制器,支持以高可用方式運行 Tower 代理服務。 更強大的可觀測性 可觀測性是容器雲平台非常關鍵的一環,狹義上主要包含監控、日誌和追蹤等,廣義上還包括告警、事件、審計等。3.1.0 除了對已有的監控、日誌、告警等功能進行優化升級,還新增了更多新特性。 監控:支持圖形化方式配置 ServiceMonitor,添加集羣層級的自定義監控,同時還實現了類似於 Grafana 的 PromQL 語法高亮。 告警:在 v3.1.0 進行了架構調整,不再使用 MySQL、Redis 和 etcd 等組件以及舊版告警規則格式,改為使用 Thanos Ruler 配合 Prometheus 內置告警規則進行告警管理,兼容 Prometheus 告警規則。 通知管理:完成架構調整,與自研 Notification Manager v1.0.0 的全面集成,實現了以圖形化界面的方式對接郵件、釘釘、企業微信、Slack、Webhook 等通知渠道。 日誌:新增了對 Loki 的支持,可以將日誌輸出到 Loki [3]。還新增了對 kubelet/docker/containerd 的日誌收集。 更易用的 DevOps KubeSphere 3.1.0 新增了 GitLab 多分支流水線和流水線克隆等功能,並內置了常用的流水線模板,幫助 DevOps 工程師提升 CI/CD 流水線的創建與運維效率。大部分場景下可基於流水線模板進行修改,不再需要從頭開始創建,實現了真正的開箱即用。 靈活可插拔的集羣安裝工具 KubeKey 不僅支持 Kubernetes 1.17 ~ 1.20 在 AMD 64 與 ARM 64 的安裝,還支持了 K3s。並且,Kubekey 還新增支持 Cilium、Kube-OVN 等網絡插件。鑑於 Dockershim 在 K8s 1.20 中被廢棄,Kubekey 可用於部署 containerd、CRI-O、iSula 等容器運行時,讓用户按需快速創建集羣。 運維友好的網絡管理 KubeSphere 將 IaaS 雲平台強大的網絡能力繼承到容器雲平台,讓用户在 Kubernetes 之上獲得與 IaaS 一樣穩定、安全和易用的網絡使用體驗。v3.1.0 新增了網絡可視化拓撲圖,你可以通過拓撲圖洞悉各個服務之間的網絡調用關係。 鑑於 Calico 是目前最常用的 Kubernetes CNI 插件之一,v3.1.0 現已支持 Calico IP 池管理,也可以為 Deployment 指定靜態 IP。此外,v3.1.0 還新增了對 Kube-OVN[4] 插件的支持。 完全開源:社區化與國際化 藉助於開源社區的力量,KubeSphere 迅速走向全球,目前 KubeSphere 在全球的 90 多個國家和地區有超過 10w 下載量。v3.1.0 Console 支持中、英、繁中和西班牙語,KubeSphere 未來將進一步拓展海外市場。 KubeSphere 3.1.0 將繼續秉承 100% 開源的承諾,3.0.0 版本帶來的諸多新功能也早已在 GitHub 開源,例如 Porter[5]、OpenPitrix[6]、Fluentbit Operator[7]、 KubeKey[8]、KubeEye[9]、Notification Manager[10]、Kube-Events[11],還開源了一套前端組件庫 Kube Design[12],這些新特性的代碼與設計文檔在 GitHub[13] 相關倉庫都可以找到,歡迎大家在 GitHub 給我們 Star + Fork + PR 三連。 安裝升級 KubeSphere 已將 v3.1.0 所有鏡像在國內鏡像倉庫進行了同步與備份,國內用户下載鏡像的安裝體驗會更加友好。關於最新的 v3.1.0 安裝與升級指南,可參考 KubeSphere 官方文檔[14]。 免責聲明:本文內容由21ic獲得授權後發佈,版權歸原作者所有,本平台僅提供信息存儲服務。文章僅代表作者個人觀點,不代表本平台立場,如有問題,請聯繫我們,謝謝!

    小林coding 開源 KubeSphere

  • 20年前譭譽參半的網遊《傳奇》,背後是怎樣的故事?

    這款遊戲的背後,是 陳天橋白手起家,締造中國網絡遊戲產業的神話傳説,從娛樂帝國到投資公司,從遊戲向人腦探索, 從人生的巔峯,到如今黯淡離場,這位曾經在商業界叱吒風雲的企業家陳天橋的一生頗具傳奇色彩。 1 在他年少的時候,就已嶄露頭角,成績總是名列前茅,能夠輕鬆掌握所學知識,生成自己獨到的見解,是大家口中“別人家的孩子”。 在復旦上學期間,他也絲毫沒有懈怠。面對周圍來自全國各地的優秀人才,他變得更加積極勤奮,學習了大量的經濟學知識,這同時也為以後創業打下了良好的基礎。 畢業之後,他進入了上海陸家嘴集團,擔任董事長的祕書職位。剛入職,他就很快地適應了工作內容,迅速掌握了公司的運營模式。 日復一日的工作讓陳天橋覺得十分枯燥,擁有着過人能力的他不甘於此,渴望去更大的地方施展自己的才能。 當時互聯網剛剛興起,網絡遊戲的市場仍處於一片空白,陳天橋通過一番分析和調查,決定要搭上網絡遊戲這股熱潮。 陳天橋對於遊戲雖然一竅不通,僅僅憑藉的是自己對於市場的敏感度而堅持開設了盛大網絡。 2000年,盛大網絡幸運地得到了中華網的300萬美元投資。這時,陳天橋在得到了一筆資金後,逐漸產生了將盛大網絡打造為“網上迪士尼”的想法。 他想打造一個屬於盛大的動畫IP,為此特地買下了《黑貓警長》的版權,可因公司的種種問題,後來便放棄了這個計劃。 到了2000年年底,互聯網行業進入了寒冬。陳天橋眼看着公司瀕臨破產,滿心焦慮,試圖尋找能夠解決公司危機的辦法。 偶然中,陳天橋發現了一款韓國遊戲開發商Wemade的熱門遊戲《傳奇》想要打入中國市場,正在尋找代理商。 並且最後給陳天橋下了命令:如果盛大執意要代理遊戲,那麼中華網將撤回投資。 陳天橋卻很執着,十分相信自己的選擇,花費了30萬美元買下了《傳奇》在中國的代理權。從此,盛大網絡和中華網也一拍兩散。 《傳奇》讓盛大網絡起死回生,使它度過了最艱難的一段時期。可以説,陳天橋的眼光並沒有看錯,憑着他的“冒險精神”讓盛大成為了我國網絡遊戲產業界的霸主。 2 之後盛大網絡相繼代理了《泡泡堂》、《冒險島》、《瘋狂坦克》等多款遊戲,深受國民歡迎,公司也逐漸開始回暖。 2004年,盛大決定在納斯達克上市。上市後的盛大名聲大噪,成為了全國市值排行榜第二名的中國互聯網企業。 他僅僅用了5年時間,就登上了中國的首富寶座,也是用時最短的中國首富。彼時的他風光無限,無人不羨慕。 當時的盛大可謂是如日中天。盛大在給陳天橋帶來巨大盈利的同時,也帶來了一系列的輿論與質疑聲。 當時發生了一件轟動一時的事件:一名男性青年手裏拿着一瓶汽油和一個打火機衝進了盛大,打算自焚,多虧員工及時把火撲滅,才沒有導致災難發生。 之後,《今日説法》還報道了15歲孩子因《傳奇》殺人的事件。名為龍龍的15歲孩子,因為迷戀《傳奇》這款遊戲便和另一個小孩子起了爭執,龍龍一怒之下買了一把刀殺死了另一個孩子。 對陳天橋的輿論鋪天蓋地席捲而來,大眾稱他為“電子鴉片販賣者”,甚至連中央電視台也展開調查,將《傳奇》公開指責其為殘害青少年的“精神鴉片”。 面對無休止的辱罵和指責,陳天橋一下從雲端跌至谷底,在巨大壓力下被迫關閉了遊戲。 陳天橋思前想後,想出了一個所有人都極力反對的轉型戰略——盛大盒子,即把電視升級為網絡終端,使用户通過電視享受互動娛樂和資訊。 陳天橋孤注一擲,在這個計劃中投入了將近10億美元。然而由於其業務觸碰到了太多壁壘,被廣電總局點名指為違規,項目無奈遭遇夭折,這個耗資巨大的項目也壽終正寢了,盛大因此也失去了網遊大佬的地位。 3 2008年,盛大在收購起點中文網的基礎上成立了盛大文學公司,後來又投資紅袖添香網、收購晉江原創文學網……盛大文學幾乎佔據了整個網絡文學的市場份額。 經歷了上市擱淺後,盛大文學的核心團隊開始上演“出走”戲碼。盛大文學總裁吳文輝遞交了辭呈,之後20多名起點的作者、編輯紛紛出走。 面對內外交困的局面,盛大文學CEO侯小強面臨着巨大的壓力,逐漸精神崩潰,患上了抑鬱症,不得不選擇告病離職。 如今,盛大遊戲日漸衰老,盛大文學也節節潰敗,盛大集團已經不能挽回頹勢。 誰知,陳天橋卻突然經歷了人生的最大變故。迫於無奈,陳天橋將盛大公司私有化,出售了自己在盛大的股份,盛大最終也沒有成為他期望中的“網絡迪士尼”。 再一次把陳天橋推向風口浪尖的是在2015年。他在這一年中從公司裏套現88億美元前往美國發展,但是他之後做的事情卻激起了中國人民的憤怒。 陳天橋的行為引起了軒然大波,遭到了許多人的口誅筆伐。質問他身為中國人,為何願意花錢給美國,卻不願意拿這錢幫助中國來進行科學研究。 後來他意識到自己的言論不太恰當,又補充道:他創辦的腦科學研究院,如果能有技術成果的話,將來可以造福全人類。 但與之相對的是,我國著名神經科學專家對陳天橋的行為進行了肯定,他認為陳天橋沒有選擇國內的機構,其中恐怕也是有很多原因的,但是對科研事業的重視是值得稱讚的。 1998年,陳天橋在股市賺到50萬的第一桶金,31歲時又一躍成為最年輕的中國首富,這個在商業界叱吒風雲的企業家一手締造了白手起家的創業神話。 然而,歷史的車輪總是滾滾向前發展,一切隨着陳天橋隱退後,盛大幾乎消失在中國互聯網巨頭的隊伍中。 也許正如他所説:“我不想重複自己做的事情,30歲做的事情如果40歲還在做,我會覺得自己的人生很失敗,我的夢想是一直向前看。” 免責聲明:本文內容由21ic獲得授權後發佈,版權歸原作者所有,本平台僅提供信息存儲服務。文章僅代表作者個人觀點,不代表本平台立場,如有問題,請聯繫我們,謝謝!

    程序員小灰 互聯網 網遊

首頁  上一頁  1 2 3 4 5 6 7 8 9 10 下一頁 尾頁
發佈文章