2015年工作總結

2015年即将過完，寫一下工作總結。

一、項目總結與反思

企業應用中的服務內建

年初的時候，我的工作主要集中在我們産品與另一款被稱為 DMA （動态媒體應用，不是直接記憶體通路）的媒體伺服器産品之間的內建功能上。這些內建的功能包括當一個 DMA 叢集中的一個節點崩潰時如何做故障轉移等等。

其實一套企業應用解決方案有時也是一個分布式應用，其中包含了多種服務。但是企業應用服務之間的內建的方式有時顯得很“老套”、“傳統”。企業應用中的各個服務往往各自為戰，每個服務調用方都需要處理分布式應用中會遇到的各種問題，諸如故障轉移。這是因為企業應用對伸縮性要求較低，是以這些對于分布式應用很重要的基礎服務并沒有被作為應用運作平台的一部分而實作。而網際網路應用會将服務治理、路由、資料平台等等這樣的基礎功能作為一個平台來統一實作。企業應用的開發人員也都知道高可用，但是卻不知道朝哪個方向前進，如何前進。是以網際網路企業對企業應用開發人員在技術上有所歧視也是可以了解。

我經過這一年的工作和對微服務架構的學習，在我所工作的項目中發現了更多的服務內建方面的問題：

1. 資料庫共享：在我們的産品和 DMA 內建之後，DMA 會直接通路我們産品的 LDAP 資料庫。按照微服務架構的幾點原則中就有一點是禁止這種設計的。事實也證明了這種設計到這裡各式各樣的問題。原因也很簡單，我們失去了對自己資料庫中資料完整性的控制。
2. 服務配置資訊分散管理：在網際網路或者新的企業應用中，一個服務相關的資訊，如位址、版本、狀态等都是存儲在一個專門的資料庫中，比如基于 Apache Zookeeper 開發的服務注冊查證機構。但現在在我們的架構中，這樣的資訊是每個應用自己管理。當然這麼做是有曆史原因，否則那時的設計就太有超前性了。但是，令人擔心的是，現在的公司中的技術人員并沒有意識到這種設計存在的問題。
3. 服務粒度過粗：這是 SOA 時代必然存在的設計問題。但是同樣也鮮有人意識到這個問題。
4. 服務版本混亂：使用 Accept 和 Content-Type 這兩個 HTTP header 區分服務的版本

讓使用老版本 JBoss 的項目支援 WebSocket

我們的項目可以算是個技術上老掉渣的項目了，還在使用 JBoss 4 作為應用的運作環境。吐槽的話不多說，工作還要繼續。架構、技術無法大改，為了是現有産品支援 WebSocket，最快捷的方法就是使用 Netty 支援 WebSocket。對于原有的 HTTP 服務，則通過 Netty 代理給 JBoss。

坑爹的 ApacheDS

項目中使用 OpenDS 已提供 LDAP 存儲服務。雖然選擇 LDAP 存儲服務是早期不合格的架構設計給現在挖的坑，但是因為骨感的現實，這個坑暫時還填不上。OpenDS 要收費，上司層自然出于節省成本的考慮讓我們選擇其替代者。選擇不多，ApacheDS 是其中一個。但不用不知道，一用吓一跳。ApacheDS 這個東西 bug 也很多，我們在使用過程中就發現了：

• DIRSERVER-2047: Some data can be lost when using ldapadd command to insert data into apacheds
• DIRSERVER-2053: Sometimes apacheds will throw OutOfMemoryException

ApacheDS 底層使用了一個叫 Apache Mavibot 的項目來實作 MVCC (Multi Version Concurrency Control) 存儲。我現在已經記不清這個資料結構的實作細節了，即便是 B+Tree B-Tree 什麼的也記不清了。

ApacheDS 項目的發展

一個上海 Intel 專門從事開源項目研發的哥們因為在 Apache JIRA 上看到了我們的提問而給我打電話，也聊到了 ApacheDS 這個項目。他說到 ApacheDS 這個項目目前主要是為 Hadoop 提供 Kerberos 認證服務。目前 Mavibot 這個項目 bug 多得也讓他們累覺不愛。未來的計劃是基于想 Zookeeper 這樣的分布式存儲提供樹狀存儲的基礎實作。

支援 NTLM 的負載均衡器

為了使産品的架構向微服務方向轉變，我們需要選擇一個反向代理産品，以實作外部服務之間的負載均衡，内部服務之間的服務查找路由等功能。因為企業應用在伸縮性方面要求相對簡單，是以隻需要考慮 HTTP 和 TCP 層面的負載均衡。我負責了技術調研。這似乎不是一件難事，但是如果考慮到公司各個産品大量使用的 NTLM 認證協定，那選擇範圍就不大了。NTLM 協定的特點是雖然認證資訊是通過 HTTP、LDAP 這樣的應用層協定傳輸，但是 NTLM 協定也同樣會關注 TCP 的一些情況。具體來說就是 NTLM 認證會話必須是在同一個 TCP 連接配接裡完成，否則便會失敗。基于 HTTP 的 NTLM 認證過程通常是這樣的：

-> 普通請求

<- 401 Unauth Response

-> T1（請求）

<- T2（響應）

-> T3（請求）

<- 200 OK Response

經過調研我發現，Nginx 沒有哪種配置可以使其很好地支援 NTLM 協定。HAProxy 的 HTTP Tunnel 模式可以很好地支援，即前後端的連接配接會保持唯一性。但是，我們的負載均衡的技術選型除了要考慮 NTLM 協定以外，還要考慮一些來自特殊部門的安全方面的要求。這些要求往往需要一些自定義的開發工作，是以 HAProxy 也被排除出去。因為對它的自定義開發沒有經驗，且會引入新的語言，而且還有協定方面的顧慮。

最終還是選擇了以 Netty 為基礎開發負載均衡器。目前項目在年底開始向支援完整的 HTTP 和 TCP 路由配置的方向發展。

從事項目管理

五月份公司開始了一個新的解決方案的研發工作。這個新方案涉及到了兩個伺服器端産品和三個終端産品，整個團隊分散在四個國家。我主要負責7月份的時候因為工作的原因去以色列出差工作兩周。工作間隙領略了耶路撒冷古老城牆、雅法老城、馬薩達遺址。當然也去死海裡面泡了泡。

以色列其實是一個很安全的國家，尤其是遠離巴以邊境的地方。街上不時能看到持槍的士兵，不過那是因為以色列士兵即便在休假的時候也槍不離手。以色列人還是很友好的，除了剛下飛機被便衣問了幾個簡單的問題，其實我覺得也是例行公事。

出國工作還是很鍛煉英語的，一天到晚都是不停滴說英語，自己在工作方面英語是夠了，但是在非工作方面還是有些費力，主要是詞彙量還是太有限。好在自己臉皮厚，聽不懂了就讓對方拼一下單詞，手機一查也就懂了。

更加坑爹的 Calendar Proxy 項目

我們有一個功能叫 Calendar Proxy，這個功能是以 MS Exchange、Office 365、Google Calendar 等月曆服務為基礎，提供一個通用的月曆 API，并提供和我們公司業務相關的一些額外資料。這些資料的細節就不說了。總體而言，這個功能實作起來并不複雜。美國研發部的一個老外實作了這個功能。結果是這個老外吹得比天高，花了半年多做的卻渣一樣的爛。無奈我們産品還必須內建這一功能。吐槽的話就不再說了。總之在浪費了大量時間，加了N天班之後，我最終花了兩天實作了性能高了至少一個數量級的新實作。

從好的方面看，這個不靠譜的功能讓我有機會去實踐 Wireshark，加深了對 TCP 的了解，認識了 NTLM 協定（雖然用的越來越少），再次有了一個實踐 Netty 的機會。

現在用 Netty 實作 Calendar Proxy 的工作依舊在進行中。

二、學習

技術分享

年初第三次讀了一遍《Java并發程式設計實戰》，之後做了若幹關于并發程式設計的技術分享。第一個題目是整體介紹了 Java 并發和異步程式設計，之後介紹了一些具體的内容，包括“Java 線程池的構造函數的參數詳解，以及内部實作原理”、“Java 線程池中的異常處理”、“線程饑餓死鎖”、“Schedule 線程池的實作”、“Java 8 Stream”、“分布式技術概述”、“微服務概述”。

推動工程師文化建設

年初的時候給上司提議加強跨部門的技術交流。主要通過定期的技術分享活動、教育訓練、對各自産品的介紹，等等的形式加強工程師文化的建設。同時可以分享各部門已有的成果，提高工作效率，降低研發成本。寫過郵件，也找上司談過，但可惜這個提議最終還是石沉大海。

讀過的書

• Java 并發程式設計實戰（第三遍）
• Java應用架構設計
• 大型網站技術架構
• 大型網站系統與Java中間件開發實踐
• 深入了解Java虛拟機

《Java 并發程式設計實戰》這本經典的書自然不必多介紹。《大型網站技術架構》和《大型網站系統與Java中間件開發實踐》是大型網站技術體系入門的好書，我隻讀過一遍，接下來我會再讀一遍，并寫下總結。

我現在在讀的是《深入了解Java虛拟機》，邊讀邊寫總結，相信這麼讀一遍的效果應該相當于讀兩三遍。

《Java應用架構設計》的副标題是“子產品化模式與OSGi”，OSGi 這個技術隻能算單個應用的一種候選技術，而不是大型系統或網站的主要技術。但是這本書提到的子產品化設計的一些思想和技術還是值得思考的。這本書整體的水準不如其它幾本書，但是也可以已讀。

對容器技術的學習和對雲計算的思考

目前産品的傳統軟體的形态已經暴露出太多缺點。向雲計算轉型并不是什麼噱頭，而是實實在在的必行之路。從14年開始火爆的容器技術為傳統軟體的轉型鋪平了道路。在年初的時候，自己不斷地與同僚和上司提到容器化的轉型方向。最終産品的将部署在公有雲或私有雲上。如果是公有雲，可以通過 AWS VPC 之類的方式連接配接到内網。進而，通過雲計算技術，大幅降低軟體的運作、部署和維護的成本。

自己預研了 CloudFoundry、Docker、Mesos、Kubernetes 等技術，首先否定的是 CloudFoundry，然後是 k8s，原因是還不成熟（當然，過去了小半年之後，k8s 有了很多新的發展，有一些公司，比如 eBay 也開始嘗試大規模使用 k8s）。最後，将精力集中在了 Docker 和 Mesos。

版權聲明：本文為CSDN部落客「weixin_33964094」的原創文章，遵循CC 4.0 BY-SA版權協定，轉載請附上原文出處連結及本聲明。

原文連結：https://blog.csdn.net/weixin_33964094/article/details/91818150