2018年總結

從第一天當程序員開始，我以爲個人職業生涯也就兩年三年，甚至在剛入行時第一年就以爲會是最後一年，但是五年六年，八年九年過去了，我從未想過本身能夠走這麼遠。

在我最迷茫的時候，總能在網絡上找到前輩們的有相同境遇，也總能找到問題的答案，使我再也不那麼煩惱。

生活已經是不易，coder更加不易，最讓我欣慰的是，這個行業老是不乏本領高強又願意分享經驗的前輩們，讓我有堅持下去的動力。

因此，如今我只想寫一點東西，哪怕職業生涯真的終止，起碼回過頭來還能看看當時的想法和境界。

 

微服務風

近年來服務器端技術又颳起了一股微服務風，「微服務」這個名詞，就好像是橫空出世，在2014年以前的書籍、考試用書、教材中，是我博覽羣書都前所未見的，請原諒個人才疏學淺。

由於種種緣由，公司在某個項目中強制要求使用dubbo這個微服務，因而我也成爲了這個城市中微服務大軍中一員，帶領小組突破微服務技術難題。

 

 

咱們進步了嗎

一年之間，一個接一個的項目後，玩轉了微服務架構，註冊發現、熔斷、網關、消息、持續集成、容器，而後又退回來不用他們。

「空」，到頭一場空。就好像作了一場夢同樣，彷彿咱們歷來就沒接觸過微服務。

我試圖回顧一下，這一年來咱們進步了哪些，收穫了什麼，想一想也不是原地踏步。

一、spring boot。因爲spring cloud 強制要求使用spring boot，咱們用上了這個，多個項目用下來，並且發現很好用，各類需求的考驗下都沒有讓咱們失望。

二、feign。feign client面向接口的調用，他簡化了restful api的調用，本身寫的http請求工具類也許能夠退休了。

三、TDD、DDD。在某大神的指點下，面向接口的編程，遵循里氏替換原則。如今咱們只要提供服務接口的定義，就能並行開發，而後作單元測試，而不須要等服務提供者開發完消費者端才能測試。開發難度提高就是多點幾下ide自帶的重構工具和編寫單元測試用例，之前咱們也很討厭代碼寫這麼規範，但比起微服務架構的開發管理成本和運維成本，多按那麼幾下alt+enter和shift+F6簡直不算什麼。

 

對公司的意義

對研發部門的影響意義最深遠的，並非開發語言，也不是技術選型，而是樸實無華的代碼。

對公司開發管理層來講，技術框架選型最好是統一的，能夠方便管理，人員替換。

但實際狀況是不太可能的統一的，由於不多是一成不變的，最終仍是要嘗試新框架的。

好比原來用angularjs，開始嘗試vue.js，將來還有什麼咱們誰也說不許，

並且公司總有那麼幾個遺留項目，統一框架也只是一個理想狀態吧，公司要發展，那是不可能不變的。

咱們從研究dubbo和rocketmq就能看出，阿里內部確定是把全部的mq玩個遍了，當年oracle替換mysql集羣也只是一部分一部分的來。

包括京東的去.net化。

 

架構演化

除非是初創型公司，可以在創業階段生存下來的公司，公司的生命週期老是大於技術框架或架構的生命週期。

最終，咱們仍是須要好的架構風格（指代碼）去支持演化。

在這個技術框架快速變化的環境下，去尋找一些不變的真理。

 

無論開發語言如何變，公司業務不變。

無論技術框架怎麼變，業務邏輯代碼不變。

抓住了業務這個不變的點，圍繞它來作文章。

 

解決方案

分佈式系統的物理層次結構：

B/S三層：瀏覽器、服務層、數據庫；業務邏輯在服務層

C/S兩層：桌面應用胖客戶端、數據庫；業務邏輯在客戶端

C/S三層：桌面應用瘦客戶端、服務層、數據庫；業務邏輯在服務層

這一塊在咱們公司是達成共識的，沒有爭議的。

 

邏輯層次結構：

咱們如今大多的思惟是展現層->業務邏輯層->數據訪問層，業務邏輯層是沒法單獨拿出來運行、測試、重用，都要帶上數據訪問層。

這種思惟是以數據庫爲核心的。文檔和設計上也是注重er圖表結構，程序也是脫離數據庫沒法單元測試，程序開發必須等數據庫設計完成後才能開始，溝通當中也是頻繁說起表結構。

因此業務邏輯是隨着數據庫變化的，從代碼理解需求時很大程度仍是要看sql語句。

將來咱們的業務逐漸向雲平臺方向發展，勢必在數據訪問層平行引入MQ，內存數據庫，分佈式數據庫技術，提供數據的服務（一部分的服務某種程度來講也是數據訪問，好比調第三方服務，那麼服務裏面的業務是第三方的業務，不是咱們的業務，對咱們的業務來講服務就是咱們的數據訪問層）。

從代碼層面理解需求或者溝通需求會變得愈來愈困難。

 

咱們何不改變一下？只要簡單地改變。

展現層->業務邏輯層<-數據訪問層

 

近幾個項目中就強制使用這種代碼風格，小組成員也都可以很好地貫徹，是一個良好開端。

既然業務是核心，那麼把核心獨立出來，讓那些非核心就去變吧。