由聽雲、極客邦和infoq聯合主辦的中國應用效能管理行業盛宴——2016中國應用效能管理大會（簡稱apmcon 2016）在北京新雲南皇冠假日酒店隆重召開。作為國內apm領域最具影響力的技術大會，首次舉辦的apmcon以「驅動應用架構優化與創新」為主題，致力於推動apm在國內的成長與發展。
群脈scrm首席架構師 房玉峰基於雲架構的效能深度優化例項，現場分享了群脈和雲服務的成長之路 ，這對於正在利用雲服務快速迭代和發展的團隊而言具有深刻的借鑑意義。
與其說是，「天時地利人和」，不如說是被逼的走上雲的不歸路。
1.0 的時候，面對剛剛起步的雲服務，我們更多的是把它們當成「雲主機」來看待，而在那個時候，雲上也只有雲主機這種單一的服務型別，甚至連負載均衡都沒有，我們需要購買比較大的頻寬，自建負載均衡。
所有**服務和api服務都無狀態化，自建負載均衡：
基於dnspod的dns輪詢
購買ecs自建nginx的反向**
ecs靠水平擴充套件和垂直公升級；db伺服器純靠不斷的公升級配置來解決不斷增加的流量
數月之後，阿里雲做了第乙個大版本的公升級，這個時候終於有了負載均衡slb，我們也快速跟進，把ecs的頻寬降到1m，把自建的負載均衡切回了slb：
1.0的架構，可以說我們在：快開發、慢運維，尋找滿足團隊80%需求的折中點！為了快，我們在做技術選型和雲服務選型的時候會堅持8-2原則，即，如果乙個現有的雲服務或者saas服務，已經能滿足我80%的需求了，我們就放棄自建而採用。例如，當時slb並不支援ssl，我們會退而求其次用tcp**代替https的slb，slb也不支援按照http path將請求**到後端不同的伺服器上，我們就將路由規則全部用網域名稱來代替；再比如雲上沒有nas，我們會選擇加一點開發力量，把儲存切換到七牛，同時利用七牛便利的處理能力來替換我們的裁剪和託管。在這個過程中，我們也重視「慢」運維，所謂慢，其實是我們也在慢慢的構建自己的運維團隊，開始做全面的運維監控以及自動化的事情，但是我們做到工具「剛剛好」滿足我們的需求即可。
1.0 的架構，雖然我們在雲上也是剛剛起步，但是我們也還是遇到了很多的問題，有一些相信對於現在的初創團隊也會有所幫助：
slb的健康檢查很重要，一定要開，不然後端的伺服器出了故障無法自動摘除。但是，但是，一定要注意頻率！而且，記住一定要把健康檢查的access log關閉，不然可能不經意間磁碟就被access log吃光了。
阿里雲上的雲盾，不是萬能的，不要以為有了雲盾就萬事大吉。該關閉的埠一定要關閉，同時一定要開啟安全報警。我能不告訴你由於我們不重視有十幾台ecs被作了肉雞的慘痛教訓嗎… 除了雲盾，用好安全組，用好安全組，用好安全組。之前有一篇介紹安全組的文章可以參考：雲思路 | 雲服務的安全（1）網路安全組
呼之欲出的架構 2.0
1.0 的架構有很多的問題，其中最大的問題就是缺乏架構，或者說是沒有架構，然後突然有一天，你發現團隊的開發速度慢了下來，開始出現各種壞味道的苗頭和**的「臭味」：
大面積的**冗餘，a客戶和b客戶都需要的功能但是偏偏有10%的差異，由於採用了複製、小修小改而挖下了坑，後期維護成本越來越高
資料冗餘嚴重，因為冗餘而造成的資料不一致的bug頻頻出現
**裡到處充斥的「小」架構，為了解決一些複製貼上的問題，為了解決if/else的問題，四處約定了不同的規範和方案，而且比較零散
這個時候，雲在國內開始呈現一片欣欣向榮的局面：
雲服務的種類更多，除了ecs，還出現了雲資料庫，常用的rds和快取db；出現了日誌服務，大資料服務；甚至有了各種便於整合的網際網路中介軟體等。
面向開發者發聲的saas工具也一片大好：簡訊有雲片saas服務，郵件有sendcloud服務，cdn和儲存有七牛、阿里雲等等。這些服務在各個領域提供優質的提高開發效率的利器（想想當年發簡訊我們可以買簡訊貓，發郵件要和郵件廠商對接一兩個星期）。
我們的研發團隊規模也在這個時候有了乙個巨大的擴容：
由於客戶增多同時我們針對大客戶提供專屬的私人定製的服務，我們的團隊結構開始做一些調整，同時有標準產品團隊來解決通用的產品需求，以及定製團隊來服務不同行業的大客戶，團隊迅速擴大到100+。
究其各種原因，我們急需要針對1.0的架構進行調整和公升級，來解決我們在團隊結構和系統層面的問題。
產品架構 2.0
2.0 「架構」 來解決人員和團隊層面的問題
為了便於多個團隊高效的配合，我們需要有一種機制，來讓多個團隊基於同一套產品架構並行的開發和演進。為此我們借鑑了 wordpress 的外掛程式機制，在基於yii2框架之上，構建了模組系統。不同的團隊，只要基於我們的模組規範，按照約定的配置和命名約定新增模組的**，再通過git submodule的方式鏈結進來，我們的構建系統就會在部署的時候分別針對前端**和後端**進行「編譯」和「連線」，然後完成統一的發布。同時，通過管理平台讓不同的客戶可以看到不同的模組。
這樣一點簡單的改進，團隊基於規範和約定，輔以自動化的構建工具，完成了互不干擾的並行開發。
2.0 「架構」 來解決系統層面的問題
系統層面我們第一需要解決的就是模組通訊的問題，為此我們引入了訊息中介軟體服務，基於阿里雲的訊息佇列構建而來；其次面對生產環境的問題，我們急需要快速的找到線上問題的根源並提供解決方案，我們基於sls日誌服務，快速構建了api的慢響應報表系統以及錯誤日誌追蹤系統。
站在巨人肩膀上的 2.0 架構原型
利用微服務，替換現有的模組機制，來完成模組的資料隔離、服務隔離，以及模組服務的自治
全線docker化，基於docker image的自動化部署替換當前的部署方式
目前正在進行中的3.0改造，我們的思路還是會「站在巨人的肩膀上」，用最快最直接有效的方案解決我們問題。如果變化來的很容易，也許，你的團隊也就不懼怕變化！
Novell Linux首席架構師辭職
novell與微軟結盟產生的餘波仍然未了。繼去年samba核心開發人員jeremy allison為 novell的 錯誤 決定辭職轉赴google之後，今年5月4日，novell linux desktop首席架構師，著名 linux核心開發者robert love在其 blog上正式宣布，自己已...
誰來當首席架構師？
前幾天，參加某軟體公司宣布獲得投資的發布會時，發現其董事長頭上又增加了一頂帽子 首席 架構師。其實這並不奇怪，自從比爾?蓋茨給自己創造了這頂帽子之後，國內很多公司的老闆都感覺這頂帽 子比較酷，包括網易丁磊在內的很多人都給自己扣上了這頂帽子。或許他們看來，能夠稱得上是ceo 總經理的人數不勝數，但膽敢...
架構師之路 架構師思維的培養
公司的cms 綜合賦碼管理系統 是winform的cs架構。這套系統的架構師換了3屆，到現在已經幾年沒有架構師了。本來入職時，崗位目標就是這個 自動化架構師 後來和領導達成共識先爭取成為儲備架構師，因為架構首先是為業務服務的，而工控行業有許多特別的地方，不是普通的軟體技術堆疊就能做出優秀的工控軟體的...