2016年終總結

時間 2019-11-07

標籤 2016年總結简体版

原文原文鏈接

序

2016年大約一半時間在深圳，一半時間在廣州；而2015年大約一半時間在北京，一半時間在深圳。說來也是個對稱的事情。兜兜轉轉，如今又回到深圳，感受又回到了起點。這折折騰騰看起來挺好，可是不少失去了連續性，並非太好的事情。前端

回顧

這一年的關鍵詞也是跳槽，分割線也大概是在年中的時候，秉承着互聯網改變各個行業的理念，到了非互聯網公司。java

上半年

先說說上半年的這家公司，其實去年的總結也有提到了，其實去年就不大想待下去了，不過很差頻繁跳槽，好不容易熬到了過年，因此跳槽仍是挺瓜熟蒂落，不過深圳這邊可選的公司並非太多，至少不像北京那麼多，主要是有工程師文化的公司並非不少。鵝廠有着深厚的產品文化，對工程師並非太友好，具體我也就懶得說了，別人道出個人心聲：騰訊一年感覺。本來呢，我仍是秉持比較謹慎的態度的，沒有文字說出來，怕有失偏頗，不過看到同道中人也是這樣的觀點，那我也就放心了。固然，高層也有所覺察，去年聖誕晚會就有強調要警戒今日頭條這類科技公司，未來可能要顛覆掉騰訊新聞，今年也更增強調科技，老闆說，這是騰訊史上人數最多的股東大會，「第一次提出，騰訊將來要成爲一家領先的互聯網科技公司」。也許會漸漸改變吧，指望對工程師愈來愈好，好比27寸顯示器+macbook。node

下半年

上半年底到了非互聯網公司，不過仍是有些許工程師文化，mac air + 25寸顯示器 + git。說實話，不是太喜歡不用mac、不用git的公司。今年全部的技術上的成長，都在這裏了，毫無疑問，這就是跳槽的好處，不少新技術，沒有氛圍和實戰的場景，光靠本身是很難搞起來的。主要是經歷了從傳統SOA到微服務的轉變，另外因爲以前在未經歷過先後端分離，也一塊兒經歷了。微服務+docker+k8s，很濃重的devops的味道。固然也是有些磕磕碰碰，不過新技術就是要去嘗試。另外職責上從之前的純後端，到整個項目，基本上除了前端開發，其餘的多多少少都有些涉及，算是開拓了視野，也算是打雜了一些。下面就一一說一下吧。mysql

一、先後端分離

先後端分離以後，後端變得簡單一些，基本上純提供簡單的api，前端的邏輯會重一些，這就對前端工程師的能力要求會高一點。其實邏輯移到前端，對於java工程的好處是，前端是自然異步的，能夠很好地更細粒度地請求後端api，這樣服務更輕量，大大下降了出現後端服務哪裏有問題，致使整個頁面出不來的狀況，並且前端自然異步，能夠很好地併發請求，這樣能夠很好地handle個別服務故障的狀況。nginx

先後端分離以後的第二點就是要處理跨域問題，前端有兩類方式來處理這個問題，一個是使用nodejs，前端自己就能夠代理後端服務，不過這也就增長了對前端工程師的能力要求。不過前端最近技術更新太快，2016年裏作前端是怎樣一種體驗。本來本身有點想學前端的，不事後來本身折騰了一下，有點不知所措了，前端一部分愈來愈演變得像後端了，新技術太多，感受有些複雜化。另外一個處理跨域的方式就是用nginx轉發，前端工程本地開發的時候，使用node的httpproxy，配置一個nginx的地址轉發便可，這樣全部後端接口的維護都由後端統一維護，前端只管基於相對路徑的請求。本來本身走了點彎路，讓前端本身本地搭建nginx去轉發，結果發現前端對nginx實在是一竅不通，另外把api的轉發配置也給暴露到前端了，不是太友好，並且前端的開發環境並非太統一，有的用windows有的用mac，因此各類配置起來有些麻煩，期間雖然有嘗試過用docker，可是也是增長了對前端人員的要求，最後仍是迴歸到前端本地開發使用nodejs的本地代理，僅僅作本地開發用，生產環境仍是用nginx。git

說到nginx，也算是今年接觸比較多的，之前僅僅作java後端，不涉及這麼多，如今接觸nginx也算開拓視野吧。以前公司仍是用淘寶的tengine，沒想到時隔幾年openresty大勢崛起。因而，也就是開啓了nginx+lua的開發模式了。對於用慣java的來講，對於nginx的秒級重啓，感到很是的爽歪歪。一開始還不是太習慣lua這種腳本，一來沒有ide能夠提示和debug，二來對lua不是太熟悉，有些排斥。不事後來漸漸喜歡上了，主要是秒級重啓，很是之快速。另外就是使用nginx做爲api-gateway，至關地成熟，不像spring cloud的zuul，坑仍是比較多的（好比以前的一些版本不支持url中帶冒號的），另外對於java啓動慢，佔用內存多，有些不放心，因此總體仍是很是喜歡openresty，但願明年繼續進階，但願可以熟練掌握。相比於zuul，nginx惟一不大好的是不可以作到服務的自動發現，不過這個主要是看你怎麼使用了，也有經過etcd去動態配置nginx的，固然咱們沒有搞這麼複雜，整個都拋給k8s了，nginx轉發到服務暴露的externalIP，由k8s去處理服務的擴容伸縮啥的。redis

二、微服務架構

之前仍是soa(單體架構)，沒想到今年微服務這麼火，感受本身若是不是跳槽，估計沒這麼快接觸到微服務，因此，這個也是跳槽的好處。微服務與SOA的關係呢，層次不同，不是很比如較，不過大體認爲，SOA是偏架構層面的，而微服務是SOA的一種特定方法，就相似XP/SCRUM之於敏捷開發。
簡單列一下微服務的好處吧：

代碼量不會龐大，好維護，能夠2周是否能夠重寫完爲衡量目標

可根據服務的特色選擇最適合的技術來實現，能夠大膽嘗試新技術

簡化部署，能夠快速迭代發版，升級，回滾的話，影響的限度相對較小。大的單體架構，一處小的改動就發版，代價太大，不能頻繁發版，多個改動一塊兒升級，風險大

可根據團隊人員規模，組織結構去適配服務架構，保證團隊人員能夠hold住相應規模的微服務

微服務便於聚合和重用

從人才培養上，能夠給更多人提供對單個服務負責的機會，而當這些人在單個服務上面獲得足夠鍛鍊以後，就能夠給他們更多的責任，從而幫助他們逐步達成本身的職業目標，同時經過分擔職責能夠防止某一我的的負擔太重。

主要的仍是化繁爲簡，去中心化，解構，把之前的單體架構，重量級的服務都微服務化以後，各個服務之間耦合不那麼多，就能夠自由更新。不用擔憂系統升級以後，哪一個之前的舊功能受到影響，還得當心翼翼地迴歸。服務更加內聚，影響範圍在可控的範圍內。固然並非全部的服務都能這樣，好比一些公共基礎設施的服務，好比登陸服務。

咱們主要是用spring cloud全家桶來進行微服務，得益於netflix oss的技術棧，中小公司能夠不用本身重複造個輪子，spring cloud拿來即用。固然這也得益於springboot的興起，想一想之前在公司裏頭，還得研究不一樣環境的不一樣配置文件怎麼處理，而後配置文件裏頭的數據庫密碼啥的怎麼加密之類的，springboot的profile很輕鬆地能夠解決環境配置問題，spring cloud的configer server的encrpt功能則可很輕鬆地解決加密問題，一塊兒都是那麼easy，忽然間你會發現，之前本身苦苦研究的東東，在大浪潮前面被輕鬆超越。spring的不少東東都比較好用，好比spring session，輕鬆解決分佈式session問題，簡單添加幾個依賴和註解就ok了，還有spring data系列，相似的repository，經過約定的findByXXX等屏蔽底層的數據庫細節，固然裏頭有些坑，好比mongo的findOne，就是會自動取一條，而jpa的findOne，若是有多條會報錯，不過總體而言仍是挺好的，好比分頁功能就很好用，通用的方法，從pg切到oracle，改下驅動基本就ok了，根本就不用去處理oracle麻煩的分頁方式。另外，關於服務之間的熔斷，hystrix就提供了很好的支持，很是好用，大大提高服務的高可用。

Spring Boot基礎

Spring Cloud系列

忍不住說幾句Spring Cloud系列，就是eureka的設計是AP的，強調高可用，可是這個須要看場景的，有的可能喜歡CP的設計，那麼eureka就不那麼適合了。本身使用的過程當中特別想吐槽的有點就是eureka這個每次經過eureka去作服務發現，都須要等一段時間，有點費勁，另外，若是是搭配k8s一塊兒使用的話，那麼Spring Cloud全家桶的功能有些會跟k8s重疊的，好比服務路由發現。所以相對而言，若是不存在後端服務間的交叉調用，那麼其實用Spring Cloud的ribbon、eureka其實可能不是太合適，固然有hystrix仍是很好用的，不過也存在誤判。