美團點評的前世今生：
網站由人人網（原校內網）、飯否等網站的創始人王興於2010年1月建立，2010年3月4日正式上線。2010年3月4日，美團團隊正式上線。2013年11月，美團外賣上線。2015年10月8日，美團網與大衆點評網合併，新公司實施聯合CEO制度，兩家公司在人員架構上保持不變，並將保留各自的品牌和業務獨立運營[2]。2016年1月，該新公司已完成首次融資，融資額超33億美元，融資後新公司估值超過180億美元。[3]2016年9月，美團收購錢袋寶，獲得第三方支付牌照。2017年2月14日，美團打車在南京試點上線。2018年4月4日，美團以價值16億美元的公司股分外加11億美元現金，另承擔摩拜10億美元債務，收購摩拜單車，當中3.2億美元作用注資摩拜，而摩拜A輪及B輪投資者和創辦團隊將收取7.5億美元退出公司，有指收購總值達37億美元。
2018年9月19日美團點評公佈招股結果，發售價定爲69港元，招股價範圍則介乎60至72港元；淨籌325.55億港元。股份於20日在香港聯交所主板買賣，收市報72.65元，比招股價69元高出5.3%，最高報74元，最低造72元，全日成交達1.16億股，涉資84.39億港元。
2019年6月13日，美團正式宣佈更改標誌，同時使用新的標準色，由此前的藍色改爲黃色，又稱“美團黃”。線下的所有觸點和交互入口也將變爲黃色，其中包括被收購的摩拜單車。
2019年10月在北京召開以“新職業·新技能·新發展”主題的職校發佈會，宣佈“美團大學”正式成立。美團大學下設八大學院，美酒學院、袋鼠學院、美業學院、餐飲學院、婚禮學院、閃購商學院、配送學院、客服學院等多個生活服務品類。
美團點評與我：
17年，我研究生三年級，在南京面試了美團公司。很幸運，當天面試完，自我感覺良好。面試的也很流暢，感覺沒啥大問題，十一過後，就來了電話，我就順理成章的來了美團。其實當時也有其他選擇，因爲當時也不知道哪家更好，所以就沒有變，對於我，我感覺我自己到哪其實都是差不多。畢竟是抱着來大公司取經的想法。工資相差不大的情況下，沒有想改的慾望。
18年5.8號，我來到美團正式入職。記得當時剛剛來到上海，東西放在同學那，自己一個人在上海找房子。也算很幸運，遇到我之前的室友。我們快住了兩年了。今年他要和他女朋友結婚了。所以我就和他分開了。別人打算過二人世界了，我這個電燈泡是時候退場了。
5.8剛剛來到美團，其實啥也不是很懂，就在那搗鼓Java環境，看看代碼，熟悉下蘋果電腦。之前我一直用的window電腦，當時拿到蘋果電腦，還是非常幸福的。確實，對於寫代碼來說，蘋果電腦確實比window的電腦要靈活、方便的多。特別是觸摸板，確實做的非常好。對於將要入程序員這一行的同學，如果有條件，我還是非常建議入手一個。
我們小組的日常任務是做運營類相關平臺和提供審覈方面的服務。整體來說一個對集團內提供服務，一個是搭建運營類平臺給相關運營同學使用。我當時接手的是一個非常老的項目，前後端居然是一體的。當時我即要寫前端也要寫後臺。而且由於代碼非常古老，做了各種各樣的特殊邏輯。當時還用ngnix做代理，搭建環境，啓動調試都非常麻煩。不過還好，由於是運營同學使用，也不要求顯示什麼特殊效果，只要有個表格顯示就好。做這個項目時候，我還懵懵懂懂，覺得什麼人寫的，怎麼這麼坑爹。後來才知道，這個老系統快十年了，目前小組內部正在打算重構、遷移功能。對於新手，我覺得這種老項目還是不太時候，新手寫只會把項目越寫越無法維護。
第二個項目就還可以，拿到手後不就，我就和我師傅將它的web層和service分離。我覺得這個是非常明智的。service我們新搭建服務使用java8 springMVC的框架。雖然在剛剛分離時候，我們採用只分離不重構的策略，主要是由於當時裏面特殊邏輯太多，而且還比較混亂。所以儘量不要讓運營同學感知到我們在分離。分離上線的流程可以說下：先雙寫，後用哨兵灰度，最後全切。其實大部分的轉化都是這個邏輯。哨兵一定要寫好，在區分流量時候要想清除。如果日誌量比較大，可以採用抽樣打印，比較僅僅是對比，採樣。夠統計相關數據就可以。服務器比較多，考慮到切換的分佈式一致性問題，我們往往會使用redis。分佈式問題CAP一直是比較難的問題。我們這邊雖然流量高，但是有回掃機制。丟失了一部分其實也沒啥，只要有記錄，在回掃回來就好。比較不是要求實時的出結果。
第三個項目的話，是自己和另外一個同時搭建的。另外的一個同事他經驗豐富，所以他是主ower，我作爲輔助，幫助他。其實在搭建時候，其實沒啥區分。主要是同事經驗豐富，在一些問題考慮上設計上比較完善。而且有難點問題時候也是可以去請教。工作上多問，其實非常重要。我自認爲自己不是什麼厲害的大牛，很多bug，我也不知道，經常百度，問其他人。有的時候雖然看出來bug的意思，但是還是沒法解決。在這次搭建項目的過程中，邊界問題這個還是很有意思的問題。在設計項目時候，經常要和其他系統交互，對於項目的定位一定要把握住，不能毫無邊界的開發。先確定需求是否是屬於你的項目開發範圍，如果放在自己項目範圍內，會不會造成項目之間耦合度太高。項目間的交互應該怎麼處理。爲了避免項目間耦合度高，我們在調用時候，採用kafka進行交互。如果是要返回消息的話，有采用redis或者kafka獲取結果。接着就是向後設計，我開發了一個發消息通知的模塊。其實對於所有的發通知，就獲取消息本體，消息通知人發送就好。可以將這些配置全部放到一個雲上，方便更新，維護一個對應關係，在不同場景去獲取就好。正是由於我採用這樣的模式。後面很多關於消息的開發，其實僅僅是配置下信息。有的時候還是要爲以後考慮，畢竟能少寫代碼就少寫一些
最近在重構第二個項目，可以說是大換血，由於維護這個項目已經非常熟悉，大部分邏輯已經非常瞭解，加上整個調用鏈非常長，請求的時間已經讓人難以接受。整體的重構，其實是將查詢邏輯區分，分門別類，將相互不依賴的數據，採用門面模式的方式進行重構。然後每個門面起一個線程，並行查詢。接着就是對於一些重複查詢的邏輯進行緩存操作，減少重複邏輯。對於一些慢調用的情況，採用過濾的想法，對於某些場景其實是沒有返回結果，降低慢調用的次數。最後就是對外的接口，經過打點發現，有的服務在不斷重複調用同一個接口，雖然傳參數是不一樣的，但是建立連接，這個耗時還是非常恐怖的。所以暴露了一個批量查詢接口，內部採用併發的邏輯。對於數據庫的話，就是對於查詢比較複雜，查詢一個數據耗時比較驗證的查詢，建立索引查詢。經過這一系列的查詢優化。使得整體的rpc調用的結果快了近1/2.效果還是比較明顯的。接着就是減少與前端的交互，將很多功能收口於後端，讓前端按照固定邏輯開發就好。減少因爲一些小功能，還需要於前端的聯調。比較做的是運營類功能，簡單，方便，快速迭代是最實際的。
應該馬上要進入第四個項目了，項目整體來說不難，大概10個工作日，難點在於如何去對接其他系統，裏面估計爲了兼容之前的老邏輯，又會是一大堆特殊邏輯。前人埋下的坑，只能後面的同學越滾越大。到後面有的坑，完全沒法理解。
總結：
我呢一個在上海的滬漂，每天寫寫代碼。看看電影，有時候也會感慨下，上海的房價爲什麼會這麼高。希望大家和我在2020這一年少寫bug，學到本事，以後能在上海立足！！！！