前不久,獲悉有贊科技發佈了個有贊雲,聽說開發者隨便搞搞,分分鐘即可以上線一個商城,略有不明覺厲之感。好不容易抓到了正在度假的有贊 CTO 兼聯合創始人崔玉鬆老師,就絕不專業地用微信發了一堆問題列表過去。好在玉鬆老師也是絕不矯情,被催了幾回以後完美不漏地給出答覆——個人心裏實際上是感恩的。css
崔玉鬆,前阿里技術專家,喜歡折騰架構,喜歡閱讀。2013 年加入有贊做爲 CTO 兼聯合創始人,目前在有贊管理着 300 多人的技術團隊,帶領團隊致力於打造中國 SaaS 領域最好的開店軟件解決方案。前端
畢竟多年不寫代碼,很難問出顯得本身很專業的技術問題。訪談內容以下,還請你們多提建議和反饋,大不了繼續去騷擾崔玉鬆老師。web
過去基於有贊微商城、有贊微小店、有贊收銀、有贊分銷等業務沉澱了有贊雲這樣的基礎設施,後續有贊提供的全部基礎服務都將是基於有贊雲,好比剛剛發佈的有讚美業,有贊餐飲,有贊零售,未來確定還會有其餘的完整解決方案基於有贊雲而誕生。ajax
恰好有贊一直在 2B 領域深耕,咱們發現商戶不少的需求即便咱們再作 5 年 10 年也不能都知足,而市場上存在着大量優秀的開發者,這些開發者很是熟悉他們所在領域的業務模型,很是聰明也有想法,而他們的痛點在於沒有龐大的底層研發團隊支撐複雜業務,咱們深度研究以後發如今商家服務這個領域實際上在底層服務上有通用化的可能,因而咱們就想結合咱們的優點,將有贊過去的能力積累通用化改造,變成有贊雲輸出給更多優秀的開發者,讓優秀的開發者一塊兒來服務千萬級的商家。緩存
有贊雲從提出想法到對外公開發布麼,差很少 10 個月時間,涉及到的研發人數超過 200 人,沒有仔細統計過人日,確定超過 3 萬我的日,有贊雲目前仍是內測階段,離很是自如的知足市場需求,我估計至少還須要 12 個月的艱苦研發。安全
有贊雲實際上能提供超過 800 個 API,目前根據市場需求對外開放的大約接近 200 個,有贊雲效率提高主要是兩個維度,看開發者怎麼使用。服務器
若是開發者把有贊雲看成一個 PaaS 平臺,實際上幫助開發者提高效率的主要來自於他不須要設計複雜的業務模型,也不須要去購買任何的服務器,也無需關注複雜的網絡和負載的事情,其中最複雜的是業務模型,好比會員業務,實際上就很複雜,目前市面上無數作 CRM 的開發者,幾乎每一個 2B 的軟件都有 CRM 模塊,實際上作好的,屈指可數,到目前爲止,我尚未見到國內有作好的。微信
若是開發者把有贊雲當一個 SaaS 使用,實際上連業務模型均可以無論了,就變成了一個輸入輸出的通道,真的能夠作到幾分鐘就能有一個相對完美的 CRM,或者其餘有贊雲提供的基礎服務。網絡
咱們一直積極採用多機房,多地點的部署策略,全部核心數據咱們都實時存儲 3 份以上,分佈在不一樣地域機房。安全性上有贊雲一直使用國際標準的安全管理規範,將來幾個月咱們會陸續對外公佈咱們得到的國際安全認證的資格。架構
單個點看,好像也沒有特別大的坑,總體看仍是坑不少的,最大的坑就是業務發展速度太快,複雜度急速上升,招聘和組織架構沒有及時跟上業務發展,出現了你們分頭用各類方法去解決眼前問題,致使後期在統一過程當中花了不少的精力和人力。
最難解決的就是穩定性,這個穩定是由於業務的超速發展必然帶來的,穩定性上咱們差很少花了 18 個月時間,全部的研發團隊都有參與,甚至包括銷售和服務人員,咱們內部創建了故障秒級同步的措施,發生了任何一個影響稍大點故障,其餘部門都能及時得到故障信息。
這個好像真沒有,困難實際上都是預計到的,只是解決的速度跟不上,實際上若是都解決了也不是很對,要達到那種程度須要創建不少的規則,也須要花不少的時間去創建執行規則的規則,這個如今看,好像對短時間有利,長期看,沒有了灰色地帶,會束縛優秀的人的發揮。
全部的系統和架構都是演進過來的,最痛苦和最艱難的時候,我也想過有沒有什麼一蹴而就的方式能夠到達咱們想要的方向,甚至也包括請最牛逼的人才過來解決,最終都是沒有太大效果,若是你的系統不是一個很傻的人設計和開發的,基本上不可能存在一會兒會有個革命性突破,有讚的訂單系統到如今經歷 4 版的重構了,每一個重構都耗費巨大,可是每次都是有質的提高。
注:聽說有讚的技術團隊連別人家的 CTO 也不放過,另外吸取了 17 個 CTO,稱爲「多是 CTO 最多的互聯網公司」。
一、用戶能感知到的網頁速度快慢主要是首屏速度(也就是你們常說的打開速度);
二、首屏速度最主要跟 css 和首屏所需的圖片這二者的加載快慢有關。因此,咱們對於流量最大的幾個重點頁面作了首次訪問使用 css inline(不須要下載 css 文件了)、後面訪問使用緩存的 css 文件、重點資源的異步預加載、圖片 webp 適配、常規的頁面內容/圖片懶加載、spdy/http2(共用 tcp 連接,讓 ajax 請求更快) 等等一系列優化。
有贊雲接下來幾年專一於底層 PaaS 和 SaaS 服務的研發,團隊配置會發生一些變化,主要是對業務抽象,業務建模,研發系統支持(運維工具,診斷工具,測試工具),大數據上會作更多的投入,主要的緣由是有贊雲要對接各類各樣的業務類型,有各類各樣的開發者,要實質性的提高效率,這些都是必需要具有的,將來相對成熟後,咱們也但願能把咱們的一系列好用的工具提供給咱們的開發者使用,幫助他們進一步提升系統的治理水平。
咱們暫時沒有向全部開發者徹底放開,咱們作有贊雲的初衷是爲了知足商戶沒有獲得知足的需求,有贊雲目前在開發者這裏是在追求質而非量,咱們但願開發者最好是某個 2B 領域從業人員,或者是熟悉特定的 2B 領域,可以真正構建一些有用的東西,好比,咱們內測中的一些合做夥伴,有些在醫藥行業深耕了十幾年了,很是很是熟悉醫藥行業的痛點;有些在健身這個行業幹了十幾年了,本身就是健身房的老闆,老是找不到一個靠譜的軟件;有些是美容連鎖集團的負責人,有幾十人的技術團隊,可是就是怎麼作都作很差;有些是傳統 ERP、WMS 等廠商,但願能拓展本身的服務領域。相似這樣的開發者和合做夥伴是咱們但願將來半年裏服務的人羣。
聽說某員工週末在家無聊作了個有贊公益,目前用於內部的公益售賣;還有清明節因不專心拜祖 YY
出了有贊會議。其它基於有贊雲底層服務的產品還有在 Menlo 新零售春季沙龍上發佈了出來的有贊零售、有讚美業、有贊餐飲等名稱耿直的產品。
如崔玉鬆老師所說,當前的有贊雲仍是基於業務方向的服務,對於開發者來講,除了作技術外包以外,說不定還能夠經過幫助他人開商城賺外塊了。不用謝我提醒。