在過去的幾個月裡，我們已經聽到很多關於微服務的優缺點了。微服務真的只是soa嗎? 微服務確實有助於進行複雜系統架構嗎？不論大家怎麼說，有一些公司已經轉向或正準備轉向基於微服務的方法了。他們在實踐過程中分享自己獲得的正面或負面的經驗，是很自然的事。最近，droplet公司的tom livesey分享了他們的經驗。為了給討論增添一些背景資訊，tom首先介紹了droplet的需求：
\\
\\\就像很多初創公司希望快速推出初始產品一樣，剛開始我們用乙個單片rails應用來處理從支付到推送通知在內的所有功能。儘管當時還不需要擴充套件規模，但我們想，如果把一些功能分離出來，也許有好處。於是，我們逐漸分離出了乙個個的功能，現在我們有20個服務，他們大多採用sinatra或go。
\
tom的文章談到了他們在開發過程中獲得的七點經驗教訓。
\\
\\\別做太多：微服務的「微」字是關鍵。我覺得，在關於**規模與行數方面，沒有硬性規定；你要認真考慮的是，服務做的是什麼，功能是否精簡且具有良好的定義。
\
這一點是值得注意的，因為我們已經聽到，有些人認為微服務就一定要規定**量，它們甚至進一步考慮新建乙個術語，叫奈米服務。接著，tom提到，他們決定把所有能發布的都發布出來：
\\
\\\為了處理非同步事件（比如傳送電子郵件和推送通知），有必要採用某種訊息佇列機制，從而允許其他服務來偵聽某些事件，並做出相應的響應。[...] 我們的原則是，不論乙個功能對系統中的其他部分來說有多麼討厭或多麼微不足道，能發布就發布出來。發布（publishing）相當容易，發布者不用關心有多少訂閱者對這個事件感興趣，只需觸發，其他都不用管。這一點非常強大，令微服務能夠以極快的速度被構建與部署。
\
關於微服務與資料，tom這樣描述：
\\
\\\在我們構建新版droplet時，我們花費幾周時間增添了大約10個新服務。[...] 該服務偵聽所有的賬戶更新事件，並對自己的資料做出相應更新。各個服務應該有自己的資料儲存，在服務之間分享資料庫不是乙個好的做法；不過，快取來自其他服務的資料是沒問題的，只要有機制能保證快取資料是最新的。
\
在過去的幾年裡，有關soa與契約的討論已經很多了。無論是契約成熟度模型、契約版本化或soa模式，這些年來，契約一直是soa開發（包括web服務，rest或其他實現方法）中的重要部分。tom也談到了契約的重要性：
\\
\\\更改服務介面，意味著所有使用它的服務都要修改。受影響的可能是1個服務，也可能是1000個服務。所以，為了能夠滿足所有未來的客戶方，你需要預先考慮，採用好的api實踐。當然你也可以對apis進行版本化，或採用版本化的資料表示，但預先做好設計更省事。
\
\\\不可否認，採用微服務作為基礎設施是需要一定投入的。雖然在droplet我們最近才實現「收支平衡」，但我們確實體會到了好處——構建和部署服務簡直太快太簡單了。無論是簡單地採用現有工具來解決問題，還是嘗試新技術，都不會對系統中其餘部分有大的影響——這點很棒。
\
就像在過去幾年中，我們不斷聽到有關其他soa與rest方法的經驗一樣，關於微服務的實戰經驗肯定會越來越多。這些經驗可能會影響人們的選擇。在必要時，它們也會促進最佳實踐和模式的產生，從而推動微服務的發展。
\\檢視英文原文：lessons learnt using microservices
MongoDB實戰經驗分享
nosql並不是no sql，而是指not only sql。nosql的出現是為了彌補sql資料庫因為事務等機制帶來的對海量資料 高併發請求的處理的效能上的欠缺。nosql不是為了替代sql而出現的，它是一種替補方案，而不是解決方案的首選。絕大多數的nosql產品都是基於大記憶體和高效能隨機讀寫的...
Spring Cloud 微服務實戰筆記
傳統開發所有業務邏輯都在乙個應用中,開發，測試，部署隨著需求增加會不斷為單個專案增加不同業務模組 前端展現也不侷限於html檢視模板的形式,後端向前端支援需要更多的介面模組。隨著需求增多，專案變大，單體系統部署在乙個程序內部，往往修改很小的功能，為了部署上線也會影響其他功能。後期維護成本會變得越來越...
《Spring Cloud微服務實戰》開始預售
京東 亞馬遜已全面開啟預售！快來一起體驗spring cloud所帶來的全家桶式微服務架構解決方案！掃一掃前往京東購買 為什麼選擇spring cloud spring cloud簡介 版本說明 配置詳解 監控與管理 小結eureka詳解 原始碼分析 配置詳解 服務例項類配置 元資料 跨平台支援 原...