本文目錄一覽:
- 1、2017年,Web 後端出現了哪些新的思想和技術
- 2、Java開發轉DevOps開發(Java)有前途嗎?
- 3、Go語言的應用
- 4、DevOps跟從前定義的運維工程師在具體工作職責上有什麼本質的區別?
- 5、雲計算需要學習哪些課程?
- 6、什麼是devops
2017年,Web 後端出現了哪些新的思想和技術
1. 網絡交互的多樣性
1.1 Http1.1協議日漸式微,Http2和websocket,以及更多的自定義協議將會成為主流。
Web後端將不僅僅是一個web後端,而變成一個大後端,或者叫 中端+後端(這個概念阿里巴巴很早就有了)。隨着移動互聯網的發展,以及物聯網的興起(在這裡我把mobike的單車看作是物聯網的一個終端),用戶的接入方式由單純的瀏覽器,向著多種接入設備進行演進。 在這個概念之下,用戶的定義會更廣泛,站在後端的角度看來,連接上服務器的不再是一個個的用戶,而是一個個的終端,並存在多個終端同享一個用戶的情況(多端登錄)。 因此在這個趨勢之下,整個後端的接入層(比如nginx之於web)將會走向更廣闊的天地,對於任意一個設備來說,他將同時利用多種協議和多種方式連接到不同的接入點來達成自身的功能。
1.2 網絡協議與網絡信息交互的樣式多樣性
從最早的webService,到後來的json-rpc,和thrift再到如今的 protobuf(grpc)等等,我們開始為不同的數據交互設計了不同的序列化協議和調用協議,然而受到環境(移動終端的弱網絡狀態),性能(網關服務,與網絡調用)的影響,我們開始使用大量容錯性更強,數據量更小的數據傳輸方式,來滿足我們的需求。
在早先的web中,http+from表單的提交成為我們的標配,然而在今天,TCP都不一定成為必選項,UDP和UDP的改進協議都在被不同的公司進行嘗試,甚至於KCP都有可能成為大家考慮的方案之一。
2.數據多樣性開始成為設計的焦點。
2.1 在早先的web後端中,表設計和功能開發構成了日常工作的絕大部分,所有的後端人員都在試圖讓一切的用戶操作落入CRUD的抽象範疇里(比如 Restful),然而CRUD怎麼會滿足我們的抽象需求呢。
自從memcached和redis在被大量引入後端開發之後,我們可以看到,後端人員在對數據的理解上有了大量的改變,我們不再單單把數據視為RDBMS裏面的一行,而是圍繞着業務本身對數據進行了分類。最明顯的是,狀態數據的引入,在開發中,我們將用戶的部分信息,視為一個用戶的狀態,在狀態數據的基礎上,讓用戶的行為變成狀態遷移的觸發,在表現上看我們讓用戶的信息存儲到redis和memcached 里就是最RDMBS不能有效滿足我們的抽象需求的一次改進。
2.2 從狂熱的Nosql到Nosql和RDBMS的共存,代表了後端開發人員對數據這一個方式的新理解,而傳統的行存儲到列存儲,到監控常用的基於時間序列的數據庫都開始進入了我們的視野。
幾年來,大量的開發者,開始將用戶產生的數據進行了更詳細的歸類,不再是rdbms一刀切的方式, 我們會詳細地劃分出用戶的狀態數據落入到Nosql,將用戶的操作數據落入到RDBMS(表述不一定全,但在類似於訂單支付之類的具有冪等性要求的操作中要求事務的完備等),將用戶的行為統計落入時間序列數據庫, 將用戶的大量相關資源(如頭像圖片)將會落入到我們的對象存儲中。在後端開發的手冊里,數據格式的多樣性成為了必須考慮的問題。
3.圍繞着數據的收集,存儲,計算,索引查詢,分析 成為後端的常態
3.1 後端角色的含義,在人手不足的公司里,很難存在一個專註於後端業務開發的開發人員了,在大數據的浪潮下,後端開發人員開始兼職起了數據系統的開發工程師。 隨着互聯網大量技術的演進和發展,任何一個職業都很難找到一個明確的界限,因此圍繞着數據的收集,存儲,計算,分析,和索引查詢都會成為後端開發人員的必備技能。
3.2 數據收集
(1) 隨着分佈式,集群化,多IDC的發展,不同於運維的系統性能收集,後端開發開始着重於收集與應用運營過程相關的各類指標和數據,
除了日常的業務開發,同時還會伴隨着應用調用過程的耗時,目標服務可用性等數據的收集,常見的如java的 metrics,zipkin等開源第三方的工具開始被廣泛借鑒和引用。
(2) 用戶行為和終端信息的上報收集,隨着大數據的開展,以及精細化運營的要求,後端逐漸開始接觸到用戶相關信息和終端運行狀態的信息上報,
收集上來的數據不僅用於用戶的畫像分析,同時也為客服的用戶追蹤,用戶的操作行為做出決策,通常表現在當用戶投訴某一筆業務的失敗時,便於開發人員的快速定位和排錯。
3.3 數據存儲
接着上面的數據收集,數據的傳輸和存儲成為了繞不開的功能,kafka的大規模運用,HDFS,HBase等工具也開始成為了後端開發日常的一部分。
3.4 數據計算
然而存儲的原始數據是沒有價值的,後端又開始了他們的數據清洗和數據處理的道路,storm,spark成為了後端的新秀,與用戶運營統計分析(俗稱跑策略跑算法)不同,當前語境下的後端數據計算,更多是一個短耗時,小規模的計算,典型的則比如風控系統,和預警系統,針對用戶的行為和流量的多少,對惡意用戶進行甄別和快速干預。
3.5 數據索引查詢
(1) 隨着業務的擴充,任意一個app幾乎都內置了相應的搜索引擎,Lucene,solr也成為了後端程序員必備的技能之一,不管是精確搜索,還是模糊匹配,後端身上背負的業務也越來越多。
(2) 准實時數據的搜索也將成為常態,在近幾年的發展中,如何快速地在一個巨量的數據中,完成RDBMS中的 join,distinct統計等成為後端工程師不得不面對的問題
3.6 數據分析查詢
AI和深度學習已經拉開了序幕,圍繞着數據本身的挖掘,學習,也開始成為了產品側的需求,但理想歸理想,現實歸現實,後端的同學們在這個方向上仍然還是摸索狀態,但長遠來說跑不了了。
4.架構設計的更進一步
2017年里,SOA的名詞正在淡出視野,微服務成了替代SOA的高頻詞,Serverless也開始走向了廣大後端的知識技能圖譜,不管是追新也好,滿足需求也罷,我也向諸位舉例一些常見的單詞,然而掛一漏萬請諸位擔待
4.1 CQRS(命令查詢職責分離模式)
將傳統CRUD的寫操作,進行異步化,後端配合讀寫數據庫的分離。以及消息隊列的引入,將寫操作相關的一些耗時操作(驗證,走流程)等進行異步化,常見的如電商中的訂單。
4.2 actor
Erlang的actor的興起,不管是golang Goroutine,還是scala/java的akka,都在深刻地影響着後端系統的架構設計。
4.3 CRDT和最終一致性
分佈式系統的興起,也帶來了可用性和一致性的矛盾問題,協同兩個進程間的數據成為了每一個後端繞不過去的坎,為了達成最終一致性,各類方案如雨後春筍般冒出。
4.4 reactive
當android上的流行庫Rxjava,從前端走向後台的時候,也意味着後端也開始進入了響應式編程的時代,java的 vert.x就是其中的例子,那種request-response一招破萬法的時光不再有了。
5. 運維和devops對後端的要求
5.1 安全,穩定,高效,經濟
(1) 隨着業務走向穩定,以及互聯網的發展,網絡服務的安全性開始成為了後端的核心之一,由於法律的不健全,對違法分子的追責難度大,違法成本低,網絡安全攻擊將會在將來的一段時間內成為常態,這就對後端的程序特別是對外的接口設計提出了更高的要求。
(2) 多機房,異地容災,數據備份。健壯的後端一直是後端應用的要求之一。新的時間裏,後端的可用性,穩定性依然是每一個後端都要面對的問題。
(3) 以前一個用戶只有一個電腦,瀏覽網站的時候,只在獲取數據的時候與站點有交互。現在隨着電子設備,智能設備的增多,一個用戶能夠接入網絡的設備也在增多,同時長連接和並發數也會增多,因此高性能的接入網關開始成為了後端人員關注的焦點,比如圍繞着intel的dpdk各類應用也是紛至沓來。
(4) 經濟,利用雲服務的即買即用,用完即退的特點,使得在開展運營活動的時候,後端不用向運維徵求和購買大量的機器。 然而為了在運營活動的短時衝擊和突增流量的情況下後端應用能夠平穩地運行,對後端人員的部署和調度能力提出了更高的要求。
5.2 更規範的軟件開發流程
git+jenkins+ansible的開源組合,開始無法滿足開發和運維的需求,項目管理的集成,測試人員的介入,都要求後端的軟件工程工具從各自為陣的開源工具,走向一個大一統的系統,需要我們將 需求,BUG管理,迭代版本,開發,測試,灰度,藍綠部署流程都進行集成。
5.3 雲服務,容器化之爭
公有雲,私有雲,混合雲,以及容器等相關的雲計算技術,也在推動者後端的技術改革,後端面對的不再僅僅是一個物理機器,或者虛擬機,而是一個更複雜更多樣性的環境,對後端業務之外的技術和調度要求將越來越高。
相對於前端,後端實在是一個特別籠統的說法,正如上面提出的觀點,很多的技術其實並不屬於後端工程師,他們有的時候叫 運營開發工程師,有的叫大數據工程師,但為了相對於前端的劃分,因此我把他們的工作內容都划到了後端裏面去,畢竟相對於技術研究,他們面對的都是一些技術應用的場合,很多的開源軟件只要達到了理解原理如何使用的水平就已經足夠應付日常工作了。
Java開發轉DevOps開發(Java)有前途嗎?
有沒有前途還是取決於你以後想做什麼,我從以下幾點幫助你分析下:
Java後端一年經驗轉DevOps,從組織架構上講,如果原來所在部門是業務部門,那麼現在就會去基礎設施部門(一般公司都會有這樣的部門),也就意味着你會遠離具體業務,而向更偏技術,打交道的人也會從主要跟業務部門,變成從主要跟運維和服務治理團隊。如果你以後或者現在想夯實技術,那麼現在DevOps這個機會可以抓住。
DevOps是企業技術發展到一定程度才需要關注的(小微企業更關注的是如何活下來,而不會優先考慮如何讓研發效率更高),所以有精力搞DevOps的公司,要麼發展良好,要麼是大廠,不可否認,職業生涯中有幾個大廠的標籤會對以後發展有利,且會增長見識。無論哪種,對於公司來說,核心都是希望規範並自動研發流程,以整體降本增效。另外,做DevOps,不僅僅需要Java,可能需要了解好幾種語言(如python,Golang,JS等,但不用做到開發完整項目),還可能需要接觸到容器化技術(業界常見是Docker+K8S組合),根據公司的現狀而可能細節不同。
所以還是要看以後想做什麼,如果以後想做偏業務的架構師,那這些東西可能不需要都深入了解,也不需要都完整實踐,只需要知道基本原理和大概怎麼做就行。如果希望走純技術方面的架構師(偏基礎設施和中間件),那麼DevOps是一個很好的切入點,還有不明白去問百度。
Go語言的應用
Go語言由Google公司開發,並於2009年開源,相比Java/Python/C等語言,Go尤其擅長並發編程,性能堪比C語言,開發效率肩比Python,被譽為「21世紀的C語言」。
Go語言在雲計算、大數據、微服務、高並發領域應用應用非常廣泛。BAT大廠正在把Go作為新項目開發的首選語言。
Go語言應用範圍:
1、服務端開發:以前你使用C或者C++做的那些事情,用Go來做很合適,例如日誌處理、文件系統、監控系統等;
2、DevOps:運維生態中的Docker、K8s、prometheus、grafana、open-falcon等都是使用Go語言開發;
3、網絡編程:大量優秀的Web框架如Echo、Gin、Iris、beego等,而且Go內置的 net/http包十分的優秀;
4、Paas雲平台領域:Kubernetes和Docker Swarm等;
5、分佈式存儲領域:etcd、Groupcache、TiDB、Cockroachdb、Influxdb等;
6、區塊鏈領域:區塊鏈裏面有兩個明星項目以太坊和fabric都使用Go語言;
7、容器虛擬化:大名鼎鼎的Docker就是使用Go語言實現的;
8、爬蟲及大數據:Go語言天生支持並發,所以十分適合編寫分佈式爬蟲及大數據處理。
DevOps跟從前定義的運維工程師在具體工作職責上有什麼本質的區別?
DevOps是一個體系,不僅僅是某個崗位,是從總體提高企業IT部門運作效率出發的。
如何提高運作效率這個事情比較複雜也難以抽象,所以很多人就把DevOps具象成了建立一套有效率的開發運維工具,通過這個工具提升個體和團隊協作的效率。
為了做出和使用這些工具,就會要求運維人員具備一系列的技能,比如要會Python、Go語言的開發,要會使用Puppet、Ansible、Saltstack等一系列工具,並能對這些工具進行二次開發。
如果去做一個號稱是DevOps的崗位,多半會需要掌握上述技能。
雲計算需要學習哪些課程?
雲計算學習課程大綱
1.Linux雲計算網絡管理實戰
2.Linux系統管理及服務配置實戰
3.Linux Shell自動化運維編程實戰
4.開源數據庫SQL/NOSQL運維實戰
5.大型網站高並發架構及自動化運維項目
6.網站安全滲透測試及性能調優項目實戰
7.公有雲運維技術項目實戰
8.企業私有雲架構及運維實戰
學雲計算可從事的職業
1、雲系統管理員:配置和維護的系統,包括基本的雲平台,解決出現的問題,並計劃未來雲的能力要求。
2、雲計算工程師:負責雲計算和數據中心項目交付計劃和技術方案的制定,負責雲基礎架構、上雲數據遷移、雲容災備份以及雲可靠性、安全性等的規劃設計及實施工作。
3、雲計算開發工程師:負責設計和開發面向雲服務的分佈式軟件。
4、雲計算架構師:領導雲計算項目的開發和部署,確保系統的可擴展性、可靠性、安全性、可維護性,並在預算內達到業務和IT業績表現要求。
5、運維工程師:負責雲計算項目實施和運維,做好網絡存儲、數據庫、備份、恢復、同步等相關工作。
什麼是devops
在軟件開發的過程中,開發人員負責編寫代碼,然後將代碼交給 QA(質量保障)團隊進行測試,然後將最終的發佈版交給運維團隊去布署。
DevOps 就是 Development(開發)和 Operations(運維)兩個詞的組合。但這裡的組合併不是簡單地將兩個團隊合併,而是要從思維和流程上變革,根據 DevOps 思想重新梳理全流程的規範和標準。
DevOps 既是一種思維方式,同時也是一種工作方式,作為一套促進開發、技術運營和質量保障三個部門之間的溝通、協作與整合的方法論,使得組織的快速迭代,實現競爭優勢成為現實。
在 DevOps 的流程下,運維人員會在項目開發期間就介入到開發過程中,了解開發人員使用的系統架構和技術路線,從而制定適當的運維方案。而開發人員也會在運維的初期參與到系統部署中,並提供系統部署的優化建議。
DevOps 的實施,打破了團隊內各角色的職能壁壘,讓開發人員和運維人員更好地溝通合作,通過自動化流程來使得軟件開發的整體過程更加快捷和可靠。
原創文章,作者:GVJQ,如若轉載,請註明出處:https://www.506064.com/zh-hk/n/138921.html