來阿裡之前，工作了4年半，其中3年半在某o2o型(餐飲)創業公司。
該公司的業務是基于城市和使用者經度緯度，查找附件的餐飲商店和商品，下單和配送。
創業公司，是一類特殊的公司。條件簡單，成長過程明顯，随時間軸變化快。
這裡以一個技術人的角度，講一下我所經曆的創業公司的技術發展曆程。
基本資訊
業務角色
使用者
普通消費者，需要餐飲服務
商家
飯館、酒店，提供餐飲服務
客服
處理訂單流程，處理使用者和商家的問題
配送員
從商家取餐，送到使用者
基礎環境
centos
linux系統
tomcat
jvm容器
nginx
反向代理，負載均衡
mysql
關系型資料庫
solr
基于lucene的搜尋引擎
redis
nosql，基于key-value
mongodb
nosql，基于對象
dubbo
服務化架構
發展曆程
a.草莽時期
架構圖：
特點：一窮二白，實作功能優先。大量功能雜糅在一個工程裡。工程數量少。
主要事項：
1、工程數少，環境簡單。front.war，前台網站，還沒有使用者端手機。back.war，背景，訂單、物流等。ws.war，定時器，支付，物流等。mysql，主從。memcached一個。mongodb一個，存圖檔。
2、機房。使用南京電信托管機房，自備實體機，裝配虛拟機。
3、技術人員少，一共5個左右，沒有測試。技術力量偏弱。
4、代碼大量重複，功能大量重複。沒有複用性。
與我相關的：
1、開發搜尋，我一個人，在front.war中。當時用"sql語句+memcached+java代碼"。
搜尋商店，過濾條件包括關鍵詞、商店類型、距離範圍、價格範圍、配送方式、距離排序、平均價格排序、評分排序、分頁等。用城市id查出一個城市内的商店，放入memcached。用城市id從緩存中查出商店清單，用使用者經度緯度算距離，用各種過濾條件過濾，然後分頁。
搜尋商品，先用前面的方法找到附近的商店，然後加上商店id清單和商品名從mysql查商品清單，然後拼接商店和商品，過濾各種條件，分頁。
代碼比較混亂，效率低。
2、開發支付，我一個人，在ws.war包中。主要功能是線上支付和線上退款。
獨立設計了訂單支付表，退款批次表，退款條目表。首先接的支付方式是支付寶，然後是南京銀行。
2種支付方式都是定制代碼，重用性差，不好擴充。南京銀行剛接入時，給了一點錢做優惠活動，用南京銀行支付減免多少元。
3、我還開發了使用者端其他需求，地圖頁，使用者賬戶，領券活動等。
b.分家時期
特點：部分功能獨立成子系統，并且代碼重構。
1、獨立子系統。handset.war，使用者端手機，從ws獨立。pay.war，支付，從ws獨立。
2、開始使用搜尋引擎。使用solr來做部分搜尋功能。
3、代碼大量重複，功能大量重複。複用性還是差。
1、手機功能從ws獨立成手機子系統，我一人負責，擁有獨立子域名handset.xxx.com，handset.war，擁有獨立的centos和tomcat。代碼重構，代碼做了裁剪，去掉不相關的東西。
原有一個ios開發，新來了一個安卓開發。手機端的使用體驗待改進。
2、支付功能從ws獨立成支付子系統，我一人負責，擁有獨立子域名pay.xxx.com，獨立成pay.war。代碼做了重構，原來的結構痛點明顯，不好擴充。使用了門面模式、政策模式。
門面模式，幾個統一的對外接口，網頁支付接口，手機支付接口，二維碼支付接口，退款接口等，定好每個接口的參數，簡潔明了。
政策模式，抽象出支付父類payhandler和父類方法（網頁支付、手機支付、二維碼支付、退款）。具體的某種支付方式是支付父類的子類，如支付寶網頁支付alipayhandler，支付寶手機支付alixpayhandler。
代碼結構清晰，擴充性非常好。
3、學習和使用solr做搜尋。單獨分centos和tomcat，部署一個solr。
ws引入solr api，寫定時器，全量和增量，把商店和商品寫入solr。front引入solr api，直接查詢solr。
主搜尋頁，因為配送方式條件和距離有關不好實作，一直沒接入solr。關鍵詞下拉框使用solr，使用笨的方法，傳入附近的可見的商店id清單，和關鍵詞，速度還是挺快的。
商家接入了南京的幾家超市，超市的單店搜尋頁使用了solr，搜尋效率很高。
c.精耕細作時期
特點：推廣服務化。增加更多子系統。業務單元獨立。
1、maven推廣父子工程結構，common、client、biz、web、task。對外暴露client。
2、全面推廣服務化架構dubbo。
3、增加子系統，單點登入，搜尋引擎，清單頁，标簽系統，商家中心，活動中心，權限中心，物流中心等。
4、推廣redis，基本代替memcached。redis有豐富資料結構，做業務開發更友善。
5、mysql做了一部分垂直分庫，某些業務子系統放一個mysql。還沒有做分表，資料量沒到。
6、使用ucloud，整體環境遷移到ucloud。
1、獨立開發了單點登入系統。接入前台使用者和背景使用者，用redis做登陸資訊緩存，用dubbo做服務化。效果不錯。
2、與他人合作，開發搜尋引擎系統。
建立search工程，包裝solr的api，建立幾個簡單的管理頁面（如全量增量更新，更新指定記錄），對外用dubbo提供查詢服務。建立地圖切塊算法，利用solr的反向索引，解決部分範圍内搜尋和配送方式過濾的問題，但是solr的地圖切塊的索引檔案非常大，是個新問題。
原有的搜尋功能全部切換到搜尋引擎，包括清單頁、手機搜尋、關鍵詞下拉框等。
3、獨立開發了清單頁工程。接入搜尋引擎的服務。
4、與他人合作，開發标簽系統。與活動中心配合，給商店、商品打标。
5、部署codis，一個redis叢集。
6、管理基礎環境，如dubboadmin，solr，zookeeper。
7、嘗試新的技術hbase，hive。
進化之路
單獨看一個系統，仿佛它有生命一樣，慢慢成長。
這裡舉例，用支付和搜尋，講述技術進化之路。
a.支付進化
進化架構圖：
詳細講解：
1、早期，隻有我一個人整。包攬了需求，開發，測試，維護等。接入的支付方式少，代碼寫死了。簡單又粗暴。
2、後續，還是隻有我一個人整，支付方式漸漸增多，工程獨立，代碼重構。使用了門面模式和政策模式，擴充性好，工程比較優雅。
3、後續的後續，局部優化，交接給單獨的支付開發人員。有難度的需求，我也幫忙協助。
4、支付和退款都是異步的，思維觀念需要改變和适應。比如支付了訂單，等幾秒鐘支付狀态改變。
5、異步展現在回調通知，主要有支付回調通知，退款回調通知。
6、回調通知用http，如"http://xxxx/xx.do"，url一般不要帶參數，資料用post。
7、嚴重依賴外部api，因為支付服務是外部系統提供的。有些外部支付服務做的不夠好，如回調通知延遲十幾分鐘。
8、常用的資料校驗方式：多參數拼接成一個字元串，資訊摘要，非對稱加密rsa，數字簽名，遠端動态生成流水号
9、網頁支付接口，傳回html代碼，直接跳轉到外部支付頁面，比如支付寶頁面。
10、手機支付接口，傳回json，包含objtype，objdata等。objtype是手機網頁支付類型時，objdata是url。objtype是手機app支付類型時，objdata是對象，包含key、value對。
11、核心的表是支付表，退款批次表，退款條目表。3個表滿足了主要的需求。
b.搜尋進化
1、早期，隻有我一個人整，用的"sql語句+memcached+java代碼"，簡單又粗暴。
2、之後，還是隻有我一個人整，部署了solr。由于具體的業務規則限制，不知道怎麼實作，主搜尋沒有用solr，某些能用solr的地方用了solr。
3、後續，有别人幫忙。我搭建了solr主從叢集，合作開發了地圖切塊功能和搜尋工程，解決了部分業務規則搜尋難題，主搜尋接入search。
4、反向索引，用關鍵詞查詢文檔id。主流搜尋引擎是lucene，solr，elasticsearch。
5、solr布置到tomcat，讀寫用http。
6、solr提供主從結構，一主多從。資料有版本号version，solr(從)定時拉取資料。
7、solr的常用功能，建立執行個體，配置字段，分詞，查詢，分組統計，排序，分頁，函數。
8、使用ik中文分詞器，內建到solr中。
9、使用solr的接口類+lucene jar包+solr jar包，可以開發自定義實作類，配置到solr中使用。
10、search工程，包裝solr api，對外提供dubbo服務。search和solr對應，一主多從。
總結
1、創業公司挺鍛煉人的。資源不足，強調個人能力。一個人抗幾個系統。
2、技術方面，修行靠個人。要啃枯燥乏味的技術書籍。
3、注重知識的廣度和深度，培養綜合能力。
4、在繁瑣的工作中，培養優秀的品質，如細心和耐力。
5、按照時間線，由集中到分散，分布式、服務化是主流。
6、系統的重構和優化，是個長期的過程。
7、開發要有産品觀。在大版本疊代時，産品觀會非常強烈。
bye ##