一文談盡邊緣計算

本文閱讀時間大約22分鐘。

1. 誠意炒冷飯

最近半年裏，AI談累了、區塊鏈談倦了，大批雲計算公司找到了新的熱點——邊緣計算。我承認邊緣計算是比肩雲計算的星辰大海，可是我看到這些PR稿都是炒冷飯和自吹的尬聊。

有人會把邊緣計算說成IOT，有人會把邊緣計算說成超融合，有人會把邊緣計算說成分佈式P2P計算，有些人會把邊緣計算說成邊緣機房。

另外一些邊緣計算的PR稿純粹就是拼稿尬聊"高大上"，看不到任何有用的東西。

好事多磨，成事在天。雲計算、AI和大數據都是炒過幾回冷飯才變成盛宴的，但碰運氣炒冷飯就是浪費讀者和用戶時間了。

我從新奉上邊緣計算這盤冷飯，是帶着誠意說明：

邊緣計算的冷飯要變盛宴了。

下面的幾個章節彼此獨立，9000字的長文，能夠跳讀。

第二章：爲什麼會有邊緣計算	
第三章：邊緣計算是架構革命	
第四章：邊緣計算的產品分類	
第五章：邊緣計算的客戶價值	
第六章：邊緣計算的產品演化	
第七章：邊緣架構改造原則

2. 爲什麼會有邊緣計算

好雨知時節，	
當春乃發生，	
5G網絡出，	
邊緣計算成。

4G時代即存在的數據爆炸和海量終端接入，不管服務端仍是客戶端都承擔着巨大的壓力性，你們急需探索一條新的出路。隨着5G帶來的網絡變化，邊緣計算從隔夜冷飯變成了春夜喜雨，自身有技術可行性，業務也有迫切的需求。

2-1. 服務器端在負重前行

我能夠武斷地說，最近十幾年服務端架構一直在規避問題而非解決問題，服務端就是典型的小馬拉大車。

咱們把視角回到2010年，那時候tomcat的併發不超過800，mysql的併發就是500如下；萬兆網卡加SSD盤打破了性能瓶頸，讓不少服務端應用獲得了倍速提高，但後臺服務的設計和調優是停滯狀態的。大部分服務端程序只設計了數千併發，像LVS、Nginx這類能跑數十萬併發的服務是特型異數。

企業愈來愈須要架構師，是由於單體服務沒什麼好優化的，能優化的只是組合架構。當企業遇到海量需求時，或者隊列異步排序，或者分服務分庫。

這就像2G時代一輛轎車裝上10個摩托發動機，	
到了4G時代給大貨車裝了100個摩托發動機。	
5G時代是否是要郵輪裝65535個摩托發動機？

服務器端除了計算問題還有網絡問題，廣域網帶寬的高成本和高延遲，讓不少技術選型不具有可行性。好比主流VR都選擇本地計算，就是部署服務端VR的網絡延遲太高、帶寬需求過大。

隨着帶寬和流量降價，以及AI大數據和IOT技術的進步，服務器羣集的性能、容量和接入帶寬愈來愈捉襟見肘。

咱們去觀察那些佔據資源最多的服務器端運算（好比生成各類視頻流），大都並不須要集中處理，甚至不關注過程一致性；被CAP原則限制的分佈式服務羣集，其實該向BASE模式過渡了。

只要應用協議不變，不可能上一波寫服務端的程序員老是笨蛋，服務端深度優化餘地也不大，服務器端就像一匹拉大車的小馬，拉不動貨車就再來幾匹馬。

2-2. 客戶端受盡軟硬限制

客戶端生態有硬件和環境限制，有系統和分發渠道卡脖，C/S軟件架構上默認也把客戶端當作不可控因素。一層層限制耗盡了客戶端開發圈的活力，客戶端彷佛被「天經地義又迫不得已」的限制住了想象空間。

咱們首先看硬件配置限制，不管是電腦、手機、家用智能終端甚至工業IOT網關，在激烈的市場競爭下，客戶端硬件配置歷來就是半年就落伍，三年就淘汰。

家用智能終端大部分時間是	
閒置待機，但在響應需求的	
瞬間絕對是滿負荷運行的，	
不然就是成本控制沒到位。	

	
一個手機廠商拿捏不許是否	
該集成某種計算芯片，	
集成了新芯片會成本提高，	
不集成該芯片又缺少吸引用戶新功能。

咱們再看功耗限制，臺式機電源要捨得用銅料，手機鋰電池已經服役超過20年了，無風扇工控機的功耗影響散熱上限，IOT設備的功耗極大影響部署難度。

上述四種硬件的複合體是筆記本電腦，	
操做系統升級和低功耗SSD使其	
續航時間超過了5個小時，但玩個	
中配遊戲仍然會風扇狂轉鍵盤燙手，	
而後又沒電了。

第三個問題是軟件安裝部署的難度，商業工程軟件我不太瞭解，我就舉幾個遊戲的例子。《全戰三國》有18G，《魔獸世界》40G，集成Model的《老滾5》很容易過100G，應用下載就很麻煩，後面還有安裝和更新的難關以及版權驗證等問題。

我也藉機誠邀遊戲引擎開發者們	
談談，你們由於功耗/配置/安裝	
部署問題放棄了哪些激動人心的	
炫酷功能？看徹底文大家會意識到，	
這些限制都是能夠改變的。

最後一個問題纔是重頭戲，客戶端開發者在程序分發生態中一直是弱勢被勒索的位置。一個APP想在發佈運行——技術的、商業的、渠道的、運營的、抄襲的、黑產的，這些攔路虎或者要分享利益，或者就是要禁止你的APP。

這和上個問題的本質是相同的：	
一個客戶端應用只是個用戶進程，	
沒有權限去掌控系統全局狀態。	
但這個客戶端應用在運行過程當中，	
又依賴這些全局資源的配合。

客戶端開發，不該該被這些「天經地義又迫不得已」的軟硬件限制綁住想象空間，這些軟硬件限制在邊緣計算面前，都是好笑的擺設和無限的商機。

2-3. 5G是邊緣計算的最大助力

如今能確認爆款5G應用的人早就	
去創業了，咱們只從5G的物理特性	
看將來的架構問題。

在4G時代，舊IT架構已是累卵危石頭，幸虧CDN扛下了一大半業務負載纔沒有完全崩盤。5G會增大架構危機的壓力，讓舊架構湊合不下去，但5G的物理特性又給新架構指明瞭一條新路。

首先5G致使客戶端節點的數量和帶寬的增長，廣泛預測客戶端接入數量和接入帶寬要翻十倍百倍甚至更多，這些新興應用一開始只能降速適應舊架構，可是從工程量級上有了引入中間層的必要性。

一個系統只有5萬個QPS，	
架構師引入中間層是過分設計；	
若是新系統有5億個QPS，	
架構師引入中間層纔算是正經作設計。

你們都知道5G有高帶寬，但更有價值的是邊緣網絡的超低延遲。如今對延遲敏感的邏輯只能放到客戶端本地，而5G時代，邊緣網絡延遲穩定小於10ms。5G網卡的速率和延遲在超越不少本地設備，網卡能夠復現當年SSD盤的救駕之功。

典型5G帶寬的吞吐速率是100Mbyte/s,	
讀寫延遲10ms甚至5ms如下；	
SATA硬盤理想讀寫速率能到150Mbyte，	
而延遲則是看磁頭的運氣了。	
顯示器和鍵鼠原本就有毫秒級延遲，	
大部分用戶根本不介意多上10ms的網絡IO延遲。

當數據放在「客戶管不着、廠商摸獲得」的邊緣端時，數據的管理和運營就突破了純客戶端的藩籬了。

網盤數據能夠集中反盜版和鑑黃；	
雲主機能夠代維護，容器羣集能夠	
集中更新漏洞；若是是用戶書房的	
我的電腦就沒這些便利操做了。

服務端沒法預知客戶端會什麼時候鏈接的，客戶端須要有序排隊和數據預處理，不然容易出現瞬時擁堵。5G時代客戶端會增長十倍百倍，必須有分佈式中間節點對億萬QPS進行整流排序，並進行適度的數據預處理，這樣服務器端的壓力承載纔會有序可控。

危機危機，危險的背後就是機遇，牛頓不是第一個被蘋果砸到的人。

3. 邊緣計算是架構革命

前文聊服務端、客戶端和5G，本質都是在聊C/S架構的危機。4G時代已經把優化軟件和升級硬件的潛力榨乾了，咱們必須從架構角度引入Edge端，讓邊緣節點來承載大部分5G業務壓力。

咱們清晰的看到，邊緣計算的本質是一場架構革命：

計算機剛開篇時全部軟件都是單機軟件，單機軟件只有功能沒有服務。CS模式開始有了「服務端」的概念，服務端最先只是單機處理幾千個輕量請求，如今要數萬臺服務器端併發處理上億個重負載請求，這已經超過了C/S架構的極限。

邊緣計算的本質是CES模式取代CS模式，引入Edge端是解決CS模式跑不了重載業務的最好辦法。

在5G之前，網絡計算的延遲遠大於本機計算延遲，Edge端只能跑可緩存的視頻圖片作CDN。如今CDN是最成熟最成功的雲產品，價格戰只是瞬時商業表象，CDN從產品角度已經贏的很完全了。

有了5G低延遲網絡的支撐，Edge端能夠承擔取代本機客戶端的算力工做，能夠解決前文提到的大量服務器端和客戶端危機。

對於服務器端來講，Edge端會把訪問請求在本地網進行排序和預處理，可以承擔大流量訪問和分散計算壓力；對於客戶端來講，Edge端的運行環境可控，算力強大電量無限，Edge端計算也不依賴於雲端服務端。

Edge端是一個新增的角色，引入Edge端和服務端常見的「分久必合、合久必分」並非一回事。C/S架構引入了Edge角色必需要進行慎重繁瑣的IT架構升級，這會佔用大量人力物力，但下文會說明作這個選擇是值得作的，並且CES架構改造的難度還在可控範圍內。

4. 邊緣產品的分類

不少產品都是自稱「邊緣計算」，咱們必須將這些同名產品進行分類，不然你們說的「邊緣計算」可能根本不是同一類東西。

從產品目的來看，邊緣計算大體分爲三類，分別是物聯網邊緣計算、邊緣節點計算和P2P邊緣計算。從部署位置來看，邊緣計算能夠部署在城域網端，基站端和接入端，甚至SDK均可以叫邊緣計算。下文對幾大同名產品進行辨識，爲避免嘲諷效果，本章節沒配圖。

4-1. 物聯網邊緣計算

物聯網邊緣計算能見到震撼人心的實物照片，軟件研發又敬畏新硬件，因此這種邊緣計算最火爆。

這些邊緣計算最大的缺點是，他們只是其餘行業的附屬品，不管是箱子和卡車，仍是IOT網關加傳感器，本質上都是爲其餘服務作嫁衣。好比某知名手提箱的官網介紹，不管是拷貝數據、小型私有云仍是數據預處理，這個手提箱的最終目的仍然是讓這些數據上雲。另一些知名IOT邊緣產品，它們的目的就是認證硬件、快速接入IOT和上傳數據到雲平臺。

物聯網邊緣計算的本質着力點是物聯網或者雲計算，而不是邊緣計算。

4-2. P2P邊緣計算

P2P傳輸和計算是個古老的行業，一直走着「特定內容借流量」和「特型應用借算力」的巧路，全部的計算和傳輸負載都在客戶端，服務端只作輕量級調度。

全部的輕巧都要付出代價，整個P2P網絡裏都是招募的不穩定邊緣節點，「特定內容」和「特型應用」就是適用性不普遍、只能對接幾個大客戶的意思，而大客戶的議價把控能力太強了。

隨着5G和下文另外一種邊緣計算的興起，P2P傳輸和計算可能會拿到通用穩定的邊緣節點，最終開發出更有價值的上層應用，但它是邊緣計算的客戶而非本尊。

4-3. 服務器邊緣節點

在服務器上部署邊緣節點聽起來就很熟，不少人就笑起來了，聊這麼半天，這不就是談CDN嗎？

CDN是最成功的雲服務，大量售賣且完整解決客戶問題，	
CDN售賣殺價是商業套路，研究不出新花樣更證實其完美。	
某些淺薄的人嘲諷CDN的邏輯，有點像嘲笑胡蘿蔔沒有大蒜的味道。

邊緣網絡+邊緣IaaS算力+網站服務，這就是CDN；把網站服務換成視頻服務，這就是點直播；若是把應用層換成通用邊緣計算框架，再經過5G把延遲下降到10ms如下，這就是邊緣計算。

服務器邊緣計算和CDN並不相同，爲了擁抱通用框架，某些爲CDN優化精簡的功能要補回來，還要繼續加新功能新資源，並且用戶羣在發生變化。2020年之後，雲原生程序愈來愈多，程序員們愈來愈習慣使用K8S等新一代技術架構，這對邊緣計算也是個利好消息。

邊緣計算如今只作IaaS資源和容器雲就夠消化三年市場紅利，未來會出現（除了CDN以外）全部行業的PaaS邊緣雲。

4-4. 運營商邊緣計算

有些邊緣廠商誇大運營商的基站節點能力，其實就是作通信的和作IT的互不瞭解，智子疑鄰，本身嚇本身。

雲計算業者連鐵塔公司和運營商的分工都不瞭解，那就更沒去過基站和接入機房惡劣的施工環境了。就算有高溫X86服務器，咱們也要考慮維修難度、狹小的空間和其餘能聊一萬五千字的施工問題。

運營商若是在匯聚機房和綜合接入機房部署x86服務器，這裏比城域網機房快不了幾毫秒，網絡延遲沒發生質變。這些過分近緣小機房的覆蓋用戶過少、資源池太小，客戶從這裏獲取數據的速度會比邊緣大機房更慢。

好比某城域網機房覆蓋10萬用戶，	
默認放20臺服務器，加載100個功能模塊；	
某小型近緣節點只覆蓋1萬用戶，	
只能放2臺服務器，加載幾個功能模塊。	

	
對於本節點沒有加載的功能模塊，	
小節點或者去其餘節點借數據，	
或者引導客戶端去遠端訪問，	
兩種方法都會比城域網機房的開銷大不少。

運營商和雲廠商在4G時代就相互有過誤會，但不打不相識，最終運營商成爲了可靠的網絡供應商，在邊緣計算時代你們更會緊密合做，共同承載客戶和解決問題。

---

總結這一章節內容，我對幾種邊緣計算產品的意見很明確：

我最看好城域網機房裏的服務器邊緣節點，它們能夠自負盈虧、有通用化的潛力、有CDN作趟路先驅、到客戶羣的覆蓋和距離適中。

5. 邊緣計算的客戶價值

邊緣計算的業務價值主要體如今對客戶端的減負和控制上，讓不少過去沒法想象的業務有可行性。

這一部分和前文的2-2有重度關聯	
和重複，但前文說的更可能是限制，	
本段落更多說的是夢想。 

5-1. 硬件設計更靈活

咱們先看客戶端減負，5G邊緣網絡可能比本地磁盤等零部件速度更快，這是我的計算機從未有過的新變化。

雖然手機通信模組的功耗也不小，但手機廠商不會生產上網兩小時就沒電的手機的，對此我保持謹慎樂觀態度。給客戶端作減負，最終用戶能感受到流暢度提高和電量提高，部分用戶還會爲此付費。

咱們考慮問題要稍深一些，客戶端減負最終能讓客戶端和邊緣端融合，甚至影響到硬件設計。

好比買手機都要考慮閃存空間，iCloud買50G的空間，五年才花360塊錢，這比給Iphone擴充手機內存合算多了。當文件從集中分散到就近邊緣，客戶讀取網絡文件的速度不比本地慢，5G手機就不用買那麼貴的閃存了。當網盤的數據大到沒法下載到手機時，客戶換新機時也必須用同一品牌同一帳戶才能遷移了。

邊緣端還能給客戶端的計算壓力減負，最終讓客戶端的硬件設計方式發生改變。各類長壽命客戶端，好比智能家居、電腦還有IOT設備，其輸入輸出裝置都能用5-10年，但計算組件在三年內確定會落伍；對於手機來講，試水新硬件常常是一次冒險。廠商在設計硬件時，若是能夠將某些功能放到邊緣端，將會得到巨大的靈活性。

注意動圖，鋼鐵俠是臨時就近裝配了加強護甲。

5-2.  改變應用發佈生態

邊緣計算能夠從軟件控制層面改變整個客戶端軟件生態，技術上能夠將客戶端的運算功能所有放在邊緣端，本地只保留一個視頻播放器。這個想法雖然瘋狂但不離譜，帶來的好處顯而易見。

首先是客戶端的分發渠道的變化，如今各類分發渠道都會收APP的買路財，每一個人手機上要裝數十個APP。當任何一個APP都只是個視頻播放器時，一個短視頻APP能夠推送遊戲視頻流，一個遊戲能夠內置交友平臺，舊的APP分發渠道根本堵不住這個口子。

困擾單機軟件幾十年的盜版問題，可能經過邊緣視頻化來解決。我見到的全部雲遊戲客戶，都在向遊戲平臺類Steam方向進化，虛擬化算力是小生意，賣遊戲版權和分發渠道纔是大生意。

隨着邊緣APP的訪問流暢性逐步獲得驗證，邊緣視頻流自然比本地文件更保密安全和方便控制，各類在線辦公系統的使用體驗會和本地辦公軟件如出一轍。

軟件逃脫的只是枷鎖，得到的將是新的世界。

5-3.  單一應用留住客戶

當一個APP能夠all in one其餘APP時，用戶的訪問軌跡不會跳出該APP，給產品運營提供了新的想象空間。

如今用戶在某視頻APP裏作遊戲和電商引流，轉跳到電商和遊戲APP就結束了。而將來徹底能夠購買同同樣東西不出本APP，A用戶走的京東、B用戶走的天貓、C用戶走的自建商城；本APP推廣的遊戲也能參與內購分紅，遊戲分享視頻必須打本APP水印。

5-4.  對技術部門的價值

咱們看到了對公司全局的業務價值，再看一下對技術部門的價值，咱們要說服客戶的IT部門，配合邊緣計算作CES架構改造。

對IT部門來講，雲計算是個愛恨交織的議題，猛增的IT需求讓IT部門規模增大，可是雲資源廉價又充足，讓不少繡花針同樣細緻的架構調優變得無足輕重。大部分高級工程師面對虛擬抽象化的雲平臺，他們只能挑剔極限性能和網絡抖動，我理解這是種無聊和落寞。

在業務部門承認了邊緣計算的價值之後，這些高級工程師就能努力將CS架構改變CES架構，這種體量的架構變更並非一日之功，三五年的時間都能耗進去。咱們能夠看到一羣聰明人，能作有價值又有難度的IT技術工做，這是一個積極互利的正循環。

6.邊緣產品的演化

6-1.  邊緣和雲的關係

討論邊緣計算產品前，咱們先要清楚邊緣計算和雲計算在產品層面的關聯。

狹義上的雲計算產品是對服務器端進行替代的組件，好比虛擬機、RDS、OSS等組件；廣義上的雲計算泛指全部雲廠商爲客戶完成的IT服務。在同一個雲廠商體系下營銷售賣時，邊緣計算就是廣義雲計算的一部分，在獨立產品設計時，邊緣計算不要受其餘雲產品的誤導。

6-2.  邊緣IaaS節點羣

邊緣計算廠商先要作好IaaS節點羣，邊緣IaaS是「節點羣」而不是「資源池」，搭建和維護這個節點羣是要精工出細活的。

在邊緣場景下，算力載體選擇容器會比雲主機更合適，這是要篩選對邊緣算力和網絡有大量需求的客戶，並且爲將來作大邊緣PaaS留下技術接口。

邊緣網絡內部幾乎都是南北流量，沒有東西流量，並且它是「節點羣」而不是「資源池」，因此不能套用雲端網絡的設計運營經驗。邊緣應用90%的流量仍然是多媒體視頻，但其數據生成和分發邏輯不能抄襲CDN。

IaaS節點羣 vs 海豚一大羣

6-3.  邊緣PaaS方案

在邊緣IaaS節點羣逐步穩固的過程當中，邊緣PaaS產品會根據技術棧進化出不一樣分支，限於篇幅我只總結不展開細聊了。

首先成熟的產品大類會是定製化視頻應用，相似用戶自主跨雲調度、私有加密協議、客戶自建邊緣雲等場景。

第二大類是以雲遊戲爲技術切入點，後續將進化成全部客戶端在邊緣端計算後，本地APP實際是視頻播放器。

第三大類PaaS產品會是「IOT邊緣計算」的宿主平臺，不管工業、安防仍是家用IOT都須要邊緣端作爲承接載體。

客戶端默認就是碎片化的，邊緣PaaS是在模擬和分擔客戶端工做，因此這些PaaS平臺也會細分化；好比一樣是雲遊戲，射擊類遊戲和即時戰略遊戲的PaaS產品會有明顯區別。邊緣PaaS產品在細化過程當中會雞兔同籠的錯位競爭，最終會像一羣細分領域各自稱霸商業軟件，而不是大一統的雲服務。

最終每種PaaS方案像每種小鳥同樣不一樣

7. 邊緣改造的原則

邊緣計算要求客戶的IT服務從CS架構改爲CES架構，我從五個角度向你們解釋，IT服務作邊緣化改造時應遵循的設計原則。

第一，從Edge單點角度，Edge端單點有計算有流量，但無邏輯無狀態。

邊緣端的SLA並不高，默認每一個	
節點均可以放棄，無邏輯無狀態的	
節點隨時能夠大範圍彈性伸縮，	
也方便客戶端容錯。

第二，從資源負載角度，大量公網IO、較低鏈接延遲、大量算力負載。

這就是篩選邊緣計算的目標客戶，	
避免無心義的瞎折騰。	
若是沒有大IO低延遲需求，	
那放在雲端架構更簡單，	
若是沒有大算力負載需求，	
本地客戶端本身計算是最優解。

第三，從節點架構角度，節點間節點內彼此獨立，較少內聯依賴和相互判斷

保證高效率運算就要減小依賴，	
好比CPU算一份數據只要1ms，	
從硬盤讀數據可能要10ms，	
從雲端數據庫取數據就要100ms了。	

	
前文產品設計部分，我推薦的	
邊緣容器雲都要作功能簡化和	
性能強化，不推薦邊緣雲主機，	
就是由於VPC和雲硬盤在高性能	
邊緣場景裏價值並不大。	

	
邊緣節點會將複雜邏輯丟給雲主機，	
將持久化數據交給對象存儲服務，	
但本身不要作這些複雜邏輯。

第四，從業務數據角度，從實時一致性向最終狀態一致性優化

邊緣計算是個大規模分佈式系統，	
根據CAP原則，咱們不可能捨棄	
可分區性，而邊緣主打招牌就是	
高性能，最終只能犧牲數據的	
實時一致性了。	

	
用戶必須將業務數據拆分，對於	
強一致性數據必須放回CS架構中。	
客戶要區分：	
哪些數據是能夠覆蓋累加的，	
哪些數據是能夠冪等重試的，	
哪些數據是能夠延遲擴散的，	
運行環境要預先部署到邊緣節點，	
還要區分出大量能夠直接丟棄	
和簡單重建的數據。

第五，從工程的角度，必須作服務架構改造，自研或應用全新架構。

企業IT部門必須放棄無縫	
上邊緣的幻想，不管是自研	
仍是借鑑，都必須應用全新	
的CES架構，邊緣計算改造	
將是一場五到十年的攻堅戰。	

	
邊緣計算能帶來業務價值，	
其技術實現又這麼麻煩，	
被雲計算冷落的IT架構師們，	
很快就能回到聚光燈下舞臺中央。

8. 邊緣計算的負面焦慮

邊緣計算的各類負面焦慮，反推過來都是破繭成蝶的關鍵點。

我最擔心的是5G網絡的發展速度，最悲觀估計最近幾年都是4G降資費的性質。

5G發展過慢會致使5G應用發展過慢，但運營商不可能預建設一張空載的5G網，而5G應用不爆款，客戶就沒有改造CES架構的動力。5G應用和5G網絡是先有雞仍是先有蛋的關係，邊緣計算是忙着搭窩撿蛋的，5G發展緩慢必然會影響到邊緣計算。

個人第二個顧慮是商業模式和市場認知，會讓邊緣計算陷入低附加值的泥潭。

當前4G時代試水邊緣計算的大型客戶，他們的訴求仍然是省帶寬成本，會盡力壓縮邊緣IaaS的利潤。只有5G應用要依賴低延遲邊緣網絡，並且中型客戶也開始接入邊緣計算平臺，邊緣計算平臺纔有充分的議價權。

我最後擔憂的是從業人員的模糊蠻幹。各類邊緣計算只是名字相同，相互之間沒任何關係，從業者很難造成統一觀點和標準，很容易雞同鴨講各說各話。邊緣計算的行業跨度之大覆蓋之廣，在大部分公司裏，超出了單個產研部門的能力範圍，很容易由於部門分工而畫地爲牢。

 

附錄

宣講推廣和招賢納士

大部分IT人還太年輕，不知道單機軟件演化成CS模式時，創造了多少成功的服務器軟件公司；CES模式的變化，客戶端生態的變革，都是給咱們創造了大把大把的新機會。

我在這裏打個推廣廣告，讀完這篇文章，若是你承認邊緣計算，請擴散給大家的朋友，若是IT生態真有大變化，早一天作好擁抱變化的心理準備，才能站在更好的身位。

我在這裏再打一個招聘廣告，邊緣計算是新產品，沒有相關產品研發經驗很正常。請你結合本文內容想一下，在我這類面試官面前，你是否是最優質的邊緣產品經理和最優秀的研發人員。

 

下方查看歷史文章

JVM調優實戰：G1中的to-space exhausted問題

【譯】Linux概念架構的理解

Java 8的這個新特性，你用了嗎？

實踐基於Redis的分佈式鎖

 你再主動一點點   咱們就有故事了

本號專一於後端技術、JVM問題排查和優化、Java面試題、我的成長和自我管理等主題，爲讀者提供一線開發者的工做和成長經驗，期待你能在這裏有所收穫。

讓我知道你「在看」