困難肯定是有的。但你如果確定要轉了，就要對得起自己的決定。雖然困難，也要勇往直前。
在天涯等地區(qū)，都構建了全面的區(qū)域性戰(zhàn)略布局，加強發(fā)展的系統(tǒng)性、市場前瞻性、產品創(chuàng)新能力，以專注、極致的服務理念，為客戶提供網站制作、成都網站設計 網站設計制作定制設計,公司網站建設,企業(yè)網站建設,成都品牌網站建設,成都營銷網站建設,外貿網站制作,天涯網站建設費用合理。
知乎用戶楓淚也有和你類似的經歷。他認為golang無論是從語法還是到性能，真的是比java好太多了，java現(xiàn)在就是生態(tài)比較好，但是云服務這塊go有天然優(yōu)勢，無論是阿里，華為，騰訊，百度這些大廠，都不斷加強go語言的使用比重。go語言相對于java內存消耗少的多，也就是對于服務器方面，使用go語言可以赤裸裸的省錢。
go語言和java，go語言更有前途。
1.Java仍然是主流的企業(yè)級應用編程語言，看看阿里，華為等大廠的招聘崗位就知道了。
2.Go語言代表了未來，很多新興上市公司，如B站，高途課程等用Go做主編程語言。我所知道的一些創(chuàng)業(yè)公司，也開會嘗試用Go語言。我個人也有在我司（金融機構）推動Go語言的想法。
Go語言的流行是因為兩點：
Golang在開發(fā)效率和執(zhí)行效率上都有優(yōu)勢，對于Java開發(fā)者也很容易上手。
Go是谷歌開發(fā)的，谷歌技術好，有情懷。相比來說，Java的母公司Oracle是一個沒有情懷和技術的惡霸。
如果各用一句話來概括這3個編程語言的特點：
1.Java「就業(yè)最好」：崗位多，工資高。這個趨勢也許會持續(xù)5-10年。
2.Go語言「最有前途」，語言優(yōu)秀，家底豐厚，但暫時就業(yè)崗位還不是很多。
資薪對比：
Java和Go語言薪資水平相當，都比較高。
就業(yè)崗位數(shù)：
很多應用Python的崗位，可能不會發(fā)布招聘崗位，所以Python在工作中的使用情況應該比這個數(shù)據(jù)多的多。
Go的崗位應該也比這個數(shù)據(jù)多，可能很多新的崗位會發(fā)布到更加新興的招聘平臺上去。
最近聽到一個故事，讓我感觸頗深。
說的是一個創(chuàng)業(yè)公司砸百萬年薪，請來阿里P8做CTO，結果卻不盡如人意。
公司認為阿里P8名不副實，公司用GO語言，P8只會JAVA；公司要做APP，P8只會寫Web；公司要造自己的輪子，P8只會用開源工具，更重要的是，這位P8前端、算法一竅不通。
引得團隊抱怨連連，“阿里P8怎么這么水！”
而在阿里能升到P8，自然不可能是“水貨”，所以在這位P8看來，是公司流程不規(guī)范，讓自己一身才能無處施展，堂堂技術大牛，淪為打雜幫工。
但仔細一看，雙方說得都沒毛病，問題究竟出在哪里？
其實就是創(chuàng)業(yè)公司需要軟件開發(fā)全才，卻招來了大廠出身的技術專才，到頭來就是牛頭不對馬嘴，鬧得雙方都不愉快。
軟件工程作為一個發(fā)展超過50年的成熟行業(yè)，在一線互聯(lián)網公司，軟件開發(fā)已經是一個成體系的流水線式作業(yè)。
阿里巴巴作為國內最有代表性的互聯(lián)網企業(yè)之一，其軟件開發(fā)已成規(guī)模，開發(fā)模式就是一條完備的流水線式作業(yè)。
如此，軟件開發(fā)就要求流程化、規(guī)范化，需求、設計、開發(fā)、測試、修BUG、發(fā)布、維護，每個環(huán)節(jié)都有專人負責，大家各司其職，互不干涉。
看起來像生產車間的開發(fā)模式，是經過阿里多年沉淀得出的行之有效的結果。
在大公司，開發(fā)需要多人甚至多個團隊協(xié)作，如果分工不清，必定亂成一鍋粥。
所以規(guī)模越大的互聯(lián)網公司，程序員干的事情反而越機械，在軟件開發(fā)的流水線上做著增刪查改的螺絲釘。
這樣做的好處也是顯而易見的，一方面，肯定是提高工作效率，另一方面，如果有人離職，不會對其他開發(fā)環(huán)節(jié)造成影響，并且這種專人專崗也更容易找到頂替者。
而小公司難以支撐這么大的團隊，只能找最少的人，干最多的活。
這種人才就是全棧工程師，典型特征就是會很多技術，前端后端都精通，既能寫代碼，又能做測試搞運維，無論是寫網站還寫APP都不在話下。
乍一看，一個人搞定軟件開發(fā)全流程，這也是初創(chuàng)公司喜歡找全棧工程師的主要原因。
但對于個人來說，時間精力都是有限的，很難做到技術廣度和深度兼顧，所以很多全棧工程師看起來牛逼轟轟，但實際上外強中干，這也是很多大公司沒有全棧工程師的原因。
所以小公司即使有了全棧工程師，也不能就此高枕無憂。
雖然全棧工程師一個人可以完成一個團隊的工作，看起來控制了成本，實際上卻在無形中增加了隱性成本。
一方面，如果項目臨時出BUG，沒有專業(yè)人才來解決，而全棧工程師或因分身乏術，或因技藝不精，使得問題得不到及時解決，極有可能分分鐘就損失幾十上百萬。
另一方面，如果一個項目進行到一半，全棧工程師走了，想要找到另一個能完全匹配該項目的全棧，可謂是難上加難。要知道，創(chuàng)業(yè)公司因為技術團隊關鍵人物離職直接導致項目失敗的案例，屢見不鮮。
小公司想要省點錢真的就這么難嗎？
說來說去，這問題都是出在人身上。軟件工程這個行業(yè)看著風光，實際上還在使用最原始的手工作坊模式，每一行代碼都要手工敲寫、測試。
這也是互聯(lián)網大廠開發(fā)項目應用流水線模式作業(yè)的根本原因，可就是苦了小公司，大規(guī)模團隊養(yǎng)不起，全棧工程師又極有可能不靠譜。
話說回來，制造業(yè)手工作坊現(xiàn)在都是機器作業(yè)，那軟件工程是否能實現(xiàn)自動化呢？
程序員只需要設計軟件，代碼的編寫、測試，以及后期軟件運維，直接讓工具完成。
這樣一來，公司不需要投入大量人力，就可以完成軟件開發(fā)，簡直是直接治愈小公司的痛處啊。
可這樣的工具真的存在嗎？
存在！
近些年聲勢浩大的低代碼平臺，不就是解放程序員敲代碼的雙手嗎？
就如阿里出品的釘釘宜搭和騰訊出品的微搭，都是不需要敲寫代碼就能完成程序的搭建。
但它們都存在一個問題，那就是產生的服務或應用則都必須與平臺綁定，導致諸多的特性都需依賴于特定的低代碼平臺才可以實現(xiàn)，這樣一來，很大程度上無法保證系統(tǒng)的品質及安全。
那么有沒有能實現(xiàn)一次開發(fā)、到處部署，后續(xù)不與平臺本身強綁定的全自動工具呢？
有！它就是飛算SoFlu全自動軟件工程平臺，其理念就是把軟件工程從“人治”變成“法治”，讓軟件工程擺脫對人的依賴。
只要通過拖拉拽組件的方式輸入流程圖，平臺就能自動完成開發(fā)、測試、運維。把中小企業(yè)控制成本的痛點拿捏得死死的。
在硬件方面，飛算SoFlu提供的是SaaS服務，在瀏覽器就能進行軟件開發(fā)，無需搭建環(huán)境，對硬件基本沒有要求。
在人員方面，無需敲寫代碼的可視化開發(fā)，大幅降低軟件開發(fā)的技術門檻，即使是沒有任何開發(fā)經驗的小白，經過短時間培訓也能輕松上手。
由于大部分工作由平臺自動完成，所以應用飛算SoFlu，一個人就能完成傳統(tǒng)開發(fā)模式下10人的工作量，極大減少企業(yè)人力成本支出。
且標準化的組件會將開發(fā)經驗都會積累在平臺內部，即使項目主要參與者離開，也不會影響其正常進度。
簡直就是有技術需求的中小企業(yè)的福音！
據(jù)了解，飛算SoFlu現(xiàn)在有30天的免費試用期，用一下就知道香不香了。
趕快去官網申請使用吧！
本文主要整理自阿里巴巴計算平臺事業(yè)部資深技術專家莫問在云棲大會的演講。
合抱之木，生于毫末
隨著人工智能時代的降臨，數(shù)據(jù)量的爆發(fā)，在典型的大數(shù)據(jù)的業(yè)務場景下數(shù)據(jù)業(yè)務最通用的做法是：選用批處理的技術處理全量數(shù)據(jù)，采用流式計算處理實時增量數(shù)據(jù)。在絕大多數(shù)的業(yè)務場景之下，用戶的業(yè)務邏輯在批處理和流處理之中往往是相同的。但是，用戶用于批處理和流處理的兩套計算引擎是不同的。
因此，用戶通常需要寫兩套代碼。毫無疑問，這帶來了一些額外的負擔和成本。阿里巴巴的商品數(shù)據(jù)處理就經常需要面對增量和全量兩套不同的業(yè)務流程問題，所以阿里就在想，我們能不能有一套統(tǒng)一的大數(shù)據(jù)引擎技術，用戶只需要根據(jù)自己的業(yè)務邏輯開發(fā)一套代碼。這樣在各種不同的場景下，不管是全量數(shù)據(jù)還是增量數(shù)據(jù)，亦或者實時處理，一套方案即可全部支持， 這就是阿里選擇Flink的背景和初衷 。
目前開源大數(shù)據(jù)計算引擎有很多選擇，流計算如Storm,Samza,Flink,Kafka Stream等，批處理如Spark,Hive,Pig,Flink等。而同時支持流處理和批處理的計算引擎，只有兩種選擇：一個是Apache Spark，一個是Apache Flink。
從技術，生態(tài)等各方面的綜合考慮。首先，Spark的技術理念是基于批來模擬流的計算。而Flink則完全相反，它采用的是基于流計算來模擬批計算。
從技術發(fā)展方向看，用批來模擬流有一定的技術局限性，并且這個局限性可能很難突破。而Flink基于流來模擬批，在技術上有更好的擴展性。從長遠來看，阿里決定用Flink做一個統(tǒng)一的、通用的大數(shù)據(jù)引擎作為未來的選型。
Flink是一個低延遲、高吞吐、統(tǒng)一的大數(shù)據(jù)計算引擎。在阿里巴巴的生產環(huán)境中，F(xiàn)link的計算平臺可以實現(xiàn)毫秒級的延遲情況下，每秒鐘處理上億次的消息或者事件。同時Flink提供了一個Exactly-once的一致性語義。保證了數(shù)據(jù)的正確性。這樣就使得Flink大數(shù)據(jù)引擎可以提供金融級的數(shù)據(jù)處理能力。
Flink在阿里的現(xiàn)狀
基于Apache Flink在阿里巴巴搭建的平臺于2016年正式上線，并從阿里巴巴的搜索和推薦這兩大場景開始實現(xiàn)。目前阿里巴巴所有的業(yè)務，包括阿里巴巴所有子公司都采用了基于Flink搭建的實時計算平臺。同時Flink計算平臺運行在開源的Hadoop集群之上。采用Hadoop的YARN做為資源管理調度，以 HDFS作為數(shù)據(jù)存儲。因此，F(xiàn)link可以和開源大數(shù)據(jù)軟件Hadoop無縫對接。
目前，這套基于Flink搭建的實時計算平臺不僅服務于阿里巴巴集團內部，而且通過阿里云的云產品API向整個開發(fā)者生態(tài)提供基于Flink的云產品支持。
Flink在阿里巴巴的大規(guī)模應用，表現(xiàn)如何？
規(guī)模： 一個系統(tǒng)是否成熟，規(guī)模是重要指標，F(xiàn)link最初上線阿里巴巴只有數(shù)百臺服務器，目前規(guī)模已達上萬臺，此等規(guī)模在全球范圍內也是屈指可數(shù)；
狀態(tài)數(shù)據(jù)： 基于Flink，內部積累起來的狀態(tài)數(shù)據(jù)已經是PB級別規(guī)模；
Events： 如今每天在Flink的計算平臺上，處理的數(shù)據(jù)已經超過萬億條；
PS： 在峰值期間可以承擔每秒超過4.72億次的訪問，最典型的應用場景是阿里巴巴雙11大屏；
Flink的發(fā)展之路
接下來從開源技術的角度，來談一談Apache Flink是如何誕生的，它是如何成長的？以及在成長的這個關鍵的時間點阿里是如何進入的？并對它做出了那些貢獻和支持？
Flink誕生于歐洲的一個大數(shù)據(jù)研究項目StratoSphere。該項目是柏林工業(yè)大學的一個研究性項目。早期，F(xiàn)link是做Batch計算的，但是在2014年，StratoSphere里面的核心成員孵化出Flink，同年將Flink捐贈Apache，并在后來成為Apache的頂級大數(shù)據(jù)項目，同時Flink計算的主流方向被定位為Streaming，即用流式計算來做所有大數(shù)據(jù)的計算，這就是Flink技術誕生的背景。
2014年Flink作為主攻流計算的大數(shù)據(jù)引擎開始在開源大數(shù)據(jù)行業(yè)內嶄露頭角。區(qū)別于Storm,Spark Streaming以及其他流式計算引擎的是：它不僅是一個高吞吐、低延遲的計算引擎，同時還提供很多高級的功能。比如它提供了有狀態(tài)的計算，支持狀態(tài)管理，支持強一致性的數(shù)據(jù)語義以及支持Event Time,WaterMark對消息亂序的處理。
Flink核心概念以及基本理念
Flink最區(qū)別于其他流計算引擎的，其實就是狀態(tài)管理。
什么是狀態(tài)？例如開發(fā)一套流計算的系統(tǒng)或者任務做數(shù)據(jù)處理，可能經常要對數(shù)據(jù)進行統(tǒng)計，如Sum,Count,Min,Max,這些值是需要存儲的。因為要不斷更新，這些值或者變量就可以理解為一種狀態(tài)。如果數(shù)據(jù)源是在讀取Kafka,RocketMQ，可能要記錄讀取到什么位置，并記錄Offset，這些Offset變量都是要計算的狀態(tài)。
Flink提供了內置的狀態(tài)管理，可以把這些狀態(tài)存儲在Flink內部，而不需要把它存儲在外部系統(tǒng)。這樣做的好處是第一降低了計算引擎對外部系統(tǒng)的依賴以及部署，使運維更加簡單；第二，對性能帶來了極大的提升：如果通過外部去訪問，如Redis,HBase它一定是通過網絡及RPC。如果通過Flink內部去訪問，它只通過自身的進程去訪問這些變量。同時Flink會定期將這些狀態(tài)做Checkpoint持久化，把Checkpoint存儲到一個分布式的持久化系統(tǒng)中，比如HDFS。這樣的話，當Flink的任務出現(xiàn)任何故障時，它都會從最近的一次Checkpoint將整個流的狀態(tài)進行恢復，然后繼續(xù)運行它的流處理。對用戶沒有任何數(shù)據(jù)上的影響。
Flink是如何做到在Checkpoint恢復過程中沒有任何數(shù)據(jù)的丟失和數(shù)據(jù)的冗余？來保證精準計算的？
這其中原因是Flink利用了一套非常經典的Chandy-Lamport算法，它的核心思想是把這個流計算看成一個流式的拓撲，定期從這個拓撲的頭部Source點開始插入特殊的Barries，從上游開始不斷的向下游廣播這個Barries。每一個節(jié)點收到所有的Barries,會將State做一次Snapshot，當每個節(jié)點都做完Snapshot之后，整個拓撲就算完整的做完了一次Checkpoint。接下來不管出現(xiàn)任何故障，都會從最近的Checkpoint進行恢復。
Flink利用這套經典的算法，保證了強一致性的語義。這也是Flink與其他無狀態(tài)流計算引擎的核心區(qū)別。
下面介紹Flink是如何解決亂序問題的。比如星球大戰(zhàn)的播放順序，如果按照上映的時間觀看，可能會發(fā)現(xiàn)故事在跳躍。
在流計算中，與這個例子是非常類似的。所有消息到來的時間，和它真正發(fā)生在源頭，在線系統(tǒng)Log當中的時間是不一致的。在流處理當中，希望是按消息真正發(fā)生在源頭的順序進行處理，不希望是真正到達程序里的時間來處理。Flink提供了Event Time和WaterMark的一些先進技術來解決亂序的問題。使得用戶可以有序的處理這個消息。這是Flink一個很重要的特點。
接下來要介紹的是Flink啟動時的核心理念和核心概念，這是Flink發(fā)展的第一個階段；第二個階段時間是2015年和2017年，這個階段也是Flink發(fā)展以及阿里巴巴介入的時間。故事源于2015年年中，我們在搜索事業(yè)部的一次調研。當時阿里有自己的批處理技術和流計算技術，有自研的，也有開源的。但是，為了思考下一代大數(shù)據(jù)引擎的方向以及未來趨勢，我們做了很多新技術的調研。
結合大量調研結果，我們最后得出的結論是：解決通用大數(shù)據(jù)計算需求，批流融合的計算引擎，才是大數(shù)據(jù)技術的發(fā)展方向，并且最終我們選擇了Flink。
但2015年的Flink還不夠成熟，不管是規(guī)模還是穩(wěn)定性尚未經歷實踐。最后我們決定在阿里內部建立一個Flink分支，對Flink做大量的修改和完善，讓其適應阿里巴巴這種超大規(guī)模的業(yè)務場景。在這個過程當中，我們團隊不僅對Flink在性能和穩(wěn)定性上做出了很多改進和優(yōu)化，同時在核心架構和功能上也進行了大量創(chuàng)新和改進，并將其貢獻給社區(qū)，例如：Flink新的分布式架構，增量Checkpoint機制,基于Credit-based的網絡流控機制和Streaming SQL等。
阿里巴巴對Flink社區(qū)的貢獻
我們舉兩個設計案例，第一個是阿里巴巴重構了Flink的分布式架構，將Flink的Job調度和資源管理做了一個清晰的分層和解耦。這樣做的首要好處是Flink可以原生的跑在各種不同的開源資源管理器上。經過這套分布式架構的改進，F(xiàn)link可以原生地跑在Hadoop Yarn和Kubernetes這兩個最常見的資源管理系統(tǒng)之上。同時將Flink的任務調度從集中式調度改為了分布式調度，這樣Flink就可以支持更大規(guī)模的集群，以及得到更好的資源隔離。
另一個是實現(xiàn)了增量的Checkpoint機制，因為Flink提供了有狀態(tài)的計算和定期的Checkpoint機制，如果內部的數(shù)據(jù)越來越多，不停地做Checkpoint,Checkpoint會越來越大，最后可能導致做不出來。提供了增量的Checkpoint后，F(xiàn)link會自動地發(fā)現(xiàn)哪些數(shù)據(jù)是增量變化，哪些數(shù)據(jù)是被修改了。同時只將這些修改的數(shù)據(jù)進行持久化。這樣Checkpoint不會隨著時間的運行而越來越難做，整個系統(tǒng)的性能會非常地平穩(wěn)，這也是我們貢獻給社區(qū)的一個很重大的特性。
經過2015年到2017年對Flink Streaming的能力完善，F(xiàn)link社區(qū)也逐漸成熟起來。Flink也成為在Streaming領域最主流的計算引擎。因為Flink最早期想做一個流批統(tǒng)一的大數(shù)據(jù)引擎，2018年已經啟動這項工作，為了實現(xiàn)這個目標，阿里巴巴提出了新的統(tǒng)一API架構，統(tǒng)一SQL解決方案，同時流計算的各種功能得到完善后，我們認為批計算也需要各種各樣的完善。無論在任務調度層，還是在數(shù)據(jù)Shuffle層，在容錯性，易用性上，都需要完善很多工作。
篇幅原因，下面主要和大家分享兩點：
● 統(tǒng)一 API Stack
● 統(tǒng)一 SQL方案
先來看下目前Flink API Stack的一個現(xiàn)狀，調研過Flink或者使用過Flink的開發(fā)者應該知道。Flink有2套基礎的API，一套是DataStream，一套是DataSet。DataStream API是針對流式處理的用戶提供，DataSet API是針對批處理用戶提供，但是這兩套API的執(zhí)行路徑是完全不一樣的，甚至需要生成不同的Task去執(zhí)行。所以這跟得到統(tǒng)一的API是有沖突的，而且這個也是不完善的，不是最終的解法。在Runtime之上首先是要有一個批流統(tǒng)一融合的基礎API層，我們希望可以統(tǒng)一API層。
因此，我們在新架構中將采用一個DAG（有限無環(huán)圖）API，作為一個批流統(tǒng)一的API層。對于這個有限無環(huán)圖，批計算和流計算不需要涇渭分明的表達出來。只需要讓開發(fā)者在不同的節(jié)點，不同的邊上定義不同的屬性，來規(guī)劃數(shù)據(jù)是流屬性還是批屬性。整個拓撲是可以融合批流統(tǒng)一的語義表達，整個計算無需區(qū)分是流計算還是批計算，只需要表達自己的需求。有了這套API后，F(xiàn)link的API Stack將得到統(tǒng)一。
除了統(tǒng)一的基礎API層和統(tǒng)一的API Stack外，同樣在上層統(tǒng)一SQL的解決方案。流和批的SQL，可以認為流計算有數(shù)據(jù)源，批計算也有數(shù)據(jù)源，我們可以將這兩種源都模擬成數(shù)據(jù)表?？梢哉J為流數(shù)據(jù)的數(shù)據(jù)源是一張不斷更新的數(shù)據(jù)表，對于批處理的數(shù)據(jù)源可以認為是一張相對靜止的表，沒有更新的數(shù)據(jù)表。整個數(shù)據(jù)處理可以當做SQL的一個Query，最終產生的結果也可以模擬成一個結果表。
對于流計算而言，它的結果表是一張不斷更新的結果表。對于批處理而言，它的結果表是相當于一次更新完成的結果表。從整個SOL語義上表達，流和批是可以統(tǒng)一的。此外，不管是流式SQL，還是批處理SQL，都可以用同一個Query來表達復用。這樣以來流批都可以用同一個Query優(yōu)化或者解析。甚至很多流和批的算子都是可以復用的。
Flink的未來方向
首先，阿里巴巴還是要立足于Flink的本質，去做一個全能的統(tǒng)一大數(shù)據(jù)計算引擎。將它在生態(tài)和場景上進行落地。目前Flink已經是一個主流的流計算引擎，很多互聯(lián)網公司已經達成了共識：Flink是大數(shù)據(jù)的未來，是最好的流計算引擎。下一步很重要的工作是讓Flink在批計算上有所突破。在更多的場景下落地，成為一種主流的批計算引擎。然后進一步在流和批之間進行無縫的切換，流和批的界限越來越模糊。用Flink,在一個計算中，既可以有流計算，又可以有批計算。
第二個方向就是Flink的生態(tài)上有更多語言的支持，不僅僅是Java，Scala語言，甚至是機器學習下用的Python，Go語言。未來我們希望能用更多豐富的語言來開發(fā)Flink計算的任務，來描述計算邏輯，并和更多的生態(tài)進行對接。
最后不得不說AI，因為現(xiàn)在很多大數(shù)據(jù)計算的需求和數(shù)據(jù)量都是在支持很火爆的AI場景，所以在Flink流批生態(tài)完善的基礎上，將繼續(xù)往上走，完善上層Flink的Machine Learning算法庫，同時Flink往上層也會向成熟的機器學習，深度學習去集成。比如可以做Tensorflow On Flink, 讓大數(shù)據(jù)的ETL數(shù)據(jù)處理和機器學習的Feature計算和特征計算，訓練的計算等進行集成，讓開發(fā)者能夠同時享受到多種生態(tài)給大家?guī)淼暮锰帯?/p>
Go語言是谷歌2009發(fā)布的第二款開源編程語言。
Go語言專門針對多處理器系統(tǒng)應用程序的編程進行了優(yōu)化，使用Go編譯的程序可以媲美C或C++代碼的速度，而且更加安全、支持并行進程。
現(xiàn)在很多知名公司都在使用Go語言，比如說：Google、Facebook、騰訊、百度、阿里、京東、小米、360等。
重慶分公司
重慶分公司
