前言：這篇文章寫作過程斷斷續續持續了兩個月，終於寫完了，最近事情有些多。
這次技術會議的主辦方雖然是阿里巴巴，但是還有很多其他的互聯網企業，比如百度，新浪，騰訊，盛大，360，小米。
會議共有兩天，主要面向互聯網技術，參與者也大多是互聯網公司從業者。人還比較多，討論也比較活躍。
我主要參與的是aDev(應用架構和後端技術)，這裏簡單總結一下：
1、SOA的落地。
記得Infoq上一篇文章曾說過：大意是，當一個技術大家不再熱烈的討論它的時候，說明他已經在工作中真正的發揮作用（當然也可能被淘汰），SOA應該是如此的。雖然各大網站對它的討論熱度不在，但是從這次技術會議中，隨處可見SOA的身影。很多公司的交流都涉及到這一塊，包括淘寶，米聊，新浪，一淘等等。就像林昊在一篇文章中談到的：“SOA在大網站中已經落地，而不像企業領域中宣傳的那麼虛”。
在企業領域，提到SOA，往往意味着大量複雜，昂貴的工具。SOA更多的是一種思想，即便是沒有工具，或者是簡單的工具，也能夠讓它爲系統設計服務。可喜的是現在確實有非常優秀的構建SOA系統的開業軟件，比如這次大會是提到的thrift，zookeeper等。
這一塊我最近要深入學習一下，並且也能夠應用到我們的工作中。
2、服務的無狀態
我接觸SOA的概念有很長時間，以前其實不是十分的理解服務的無狀態的特性是什麼含義，最近有點體會。小米的一個分享中提到，要看服務是否無狀態的，就看他是否可以被kill -9。後來有人提問時他舉例說了一下，比如數據室保存在進程中而不是數據庫中，如果進程重啓，那數據就丟失了。
這可能是無狀態的一種體現，但我認爲，無狀態更主要是體現在服務提供者不應該記錄並依賴調用者的上下文信息。有狀態的幾個實例：
1、調用者調用了一個某一機器提供的服務，那麼，下一次他必須也要從這臺機器獲取服務；
2、調用某一服務之前，必須調用另外一個服務。
但是現實世界是有狀態的，要實現無狀態的服務，基本有兩個方法，一個是類似RESTful，將狀態信息轉移到客戶端；一個是建立一個分佈式的緩存系統，將狀態信息全部放到緩存中。在構造無狀態服務這一塊，函數式編程語言天生就有優勢，無狀態時它的一個特點。其他語言只要採用一定規範（比如禁止使用全局變量），也可以編寫無狀態的服務。
無狀態服務的最大的目的應該是便於系統的水平擴展，同時也能夠簡化服務調用。
我們目前的系統要轉向無狀態可能要傷筋動骨。我們的很多的api都是有狀態，組粒度的，這樣的本來目的是爲了簡化調用者開發，最大的重用代碼。有一段時間考慮主備熱備份時考慮過通過同步內存和數據庫來實現，但是後來發現內存中的很多狀態信息很分散，包括api中都是有狀態信息的。如果說我們要採用無狀態服務的，一個出發點很可能是系統熱備：無狀態的服務在加上類似於
MemcacheDB，Redis數據庫。狀態全部保存在數據庫中，並且通過數據庫進行同步。
我們的業務特點是，併發不會太大，但是邏輯複雜。這可能是我們和互聯網業務不同的地方。我們基本不會用無狀態特性來水平擴展。
3、組合服務，流程，交互
組合服務就是一個服務會調用多個基本服務，通過封裝來提供更粗粒度的服務，以達到重用，方便開發的目的。問題是組合服務中可能會記錄服務調用的進度，特別是如果這個組合服務還涉及到和調用者的交互，如何保持無狀態的特性？這個問題問過小米的嘉賓，不過沒有具體回答，參會者有人提出米聊邏輯不會這麼複雜。
確實如此，互聯網業務的一個特點是邏輯簡單，但是併發量大；而企業領域的一個特點是邏輯複雜，但是併發量一般不大。後來又參加天貓的一個分享，發現電子商務的邏輯也夠複雜，應該算是互聯網中的另類。而我們的業務特點是邏輯中很多地方都涉及到和用戶的交互，即可能在流程的任意階段，收到用戶的某些事件。
一個組合服務如果不涉及到和用戶的再次交互，那麼保持無狀態會簡單一點，按照和用戶的交互點對組合服務進一步分割是一個思路。還有一個思路是後端只提供基本服務，組合的調用，把它放到前端，類似於RESTful，將狀態信息轉移到客戶端。
分享中涉及到目前一些開源的軟件如thrift，消息隊列產品，zookeeper等。
4、去c化
能夠用腳本語言去完成的，儘量用腳本語言完成，可以提高開發的效率及質量。這是從新浪開發者演講得出的一個結論，也是最近我們正在進行的一件事情。之前我們公司的程序員主要以C爲主，即便是做業務開發也是基本用c（也會用java）。結果就是c程序開發成本和維護成本相對較高，如果業務邏輯複雜的話，更難處理，目前我們在linux服務器開發上嘗試使用python，嵌入式開發嘗試使用lua。已經嘗試了幾個項目，目前來看效果不錯。
和這個相關的一個分享是ngx_lua。Nginx 的lua擴展，總體思路應該是很“通過將lua解釋器集成進Nginx，可以採用lua腳本實現業務邏輯，由於lua的緊湊、快速以及內建協程，所以在保證高併發服務能力的同時極大地降低了業務邏輯實現成本。”。lua的運行效率相對其他腳本語言可能更好。缺點正如分享所說：基礎設施不是很完善，開源庫不夠豐富。有人提問爲什麼不考慮python，ruby等其他腳本語言，分享者的回答是這些語言不支持協程，所以直接就不在考慮範圍之內。python應該是支持協程，自帶的yield雖然實現協程受限較多，但是第三方的實現，比如greenlet還是比較成熟的，這一塊我使用的還是比較多的。我分析沒有考慮python的原因可能是python的協程實現和nginx集成有難度，同時運行性能也沒有lua好（個人猜測，對nginx不是很熟悉）。可惜後面沒有機會確認。
如果python可以的話，可讀性，語言表達力，基礎設施完備性相對lua優勢更大。
nodejs:適合IO密集，邏輯不復雜的系統。如果邏輯複雜，用回調描述邏輯是反人類認知的。這裏使用協程更好。javascript中也有很多這方面的庫。印象中老趙也開源了一個。
5、小小的遺憾
和我們領域接近的杭州的大公司，比如華爲，海康，華三等基本上都是在這種技術交流中缺席的，比較遺憾。
總結：
兩天時間學了不少東西，這裏只記錄了一些和我最近比較有共鳴的一些想法。同時，SOA和去c也是我最近的一個方向。
