微服務設計

軟件的本質困難在於軟件本身的複雜性。 我們頭腦中最多同時注意5～9件事，因此對付複雜性的方法自然而然就是——分而治之。 數據庫，模塊化，面向對象，MVC，SOA（Service-Oriented-Architecture，面向服務的架構）都是在做抽象，都是在做分而治之，都有同一個指導綱領: 高內聚，低耦合。它們的主要差別在於實現方式和關注的粒度不同。其核心都是分解複雜度，使得每小塊軟件的複雜度能被我們完全控制。 微服務架構可以看做是SOA的一種特定方法，它並不是銀彈。 它只是通過以一個個微服務的方式，來拆分整個軟件的複雜度，各個微服務間通過清晰可控的信息交流，來完成整個軟件的功能。 但是，服務分離後，所引入的一系列分佈式問題，我們仍然無法迴避。 但所幸的是，服務分離後，各個服務之間的極致的松耦合使得重用和移植變得非常容易。很容易集成一些第三方的服務，或搭建在不同平臺之上（例如:公有云，私有云，混合雲，物理集羣）。  而且，現在雲廠商都在試圖提供一整套的微服務解決方案，使得開發人員不需要去解決分佈式所引入的種種問題，只需要關注於業務邏輯本身。雲廠商幫你解決分佈式的一致性，可用性，隔離性，彈性伸縮；爲你提供安全保護，通信協議，開發工具，集成測試；提供持續集成，持續交付，灰度發佈的能力；提供完善的監控，可選的容災策略，以及運營數據的查詢與顯示；還有一系列支持用戶自定義的接口，可以方便的定製化以及和其他雲服務無縫隙兼容的能力。 因此，我覺得微服務是一個高度軟件工程化的，並且和雲結合到一起才能落地的產物。而微服務的一種極致形式就是無服務器函數，真的只需要開發人員關注服務本身。

這個星期主要是在整理自己對於微服務設計的一些思考，也回顧了Sam的這本書，根據作者的一些建議去改進了原本模式中的一些問題，比如微服務不要直接去操縱數據庫，而把這個權限交給一個人專門去做這個事情的服務來處理等等。經過優化後覺得整個後端的模式確實變得更加清晰了。倘若你們的產品也有考慮切換到微服務模式，這本書還是值得一看的。

微服務這個詞，已經出現很久了，但是一直沒有去了解一下，連最基本的概念都不清楚，然後百度了一下，瞭解了一些相關的概念，然後就找到了這本書，就大致看了一下，有些章節沒有看，因爲要看的技術很多，我目前的目標是形成自己的一個技術知識體系，所以不會在具體的技術上花費太多的時間，沒有那麼多精力去從前往後認真的看，有個大概的瞭解就差不多了，將來如果涉及到這方面的工作再去細看。 下面是微服務的一些大的原則。 第1點圍繞業務概念建模，微服務，比較難的一點是劃分上下文邊界，也就是，這個微服務，他需要實現什麼業務？另外一個，建模要圍繞着業務來而不是技術。 第2點，自動化的文化。由於把單個系統拆分成多個微服務，那麼多個微服務的部署以及之間的協同、測試就會比較複雜。如果每次部署發佈版本，都是通過手工的方式去做這些檢查的話那麼效率就太低了，所以在開發微服務之前，爲微服務提供配套的工具和流水線是非常有必要的。 第3點，隱藏內部實現細節。服務和服務之間通過對外接口來實現協作即可，而服務內部的實現不應該暴露出去，以防服務和服務之間發生耦合。 第4點是一切去中心化。應該使用單機單服務模式。如果把多個微服務部署在一臺機器上，如果服務對於機器的環境有所依賴的話，那麼，部署在一臺機器上就有可能存在兼容性問題。 第5點，獨立部署。你可以更改單個服務，然後把它部署到環境裏，並且無需聯動地部署其他的服務，這應該是常態。 第6點，隔離失敗，當其中一個服務出現異常時不能造成連級異常，所以對服務要考慮超時的處理，斷路器和艙壁等。 第7點是高度可觀察，提供日誌監控和診斷，可以方便快速的定位問題。

微服務不是免費的午餐，更不是銀彈，如果你想要得到一條通用準則，那麼微服務是一個錯誤的選擇。你需要面對所有分佈式系統需要面對的複雜性。儘管後面用很多的篇幅來講解如何管理分佈式系統，但它仍然是一個很難的問題。如果你過去的經驗更多的是關於單塊系統，那麼爲了得到上述那些微服務的好處，你需要在部署、測試和監控等方面做很多的工作。你還需要考慮如何擴展系統，並且保證它們的彈性。如果你發現，還需要處理類似分佈式事務或者與CAP相關的問題，也不要感到驚訝！ 每個公司、組織及系統都不一樣。微服務是否適合你，或者說你能夠在多大程度上採用微服務，取決於很多因素。

非常好的一本書，思想和理念講的非常好，其中裏面的一些東西還需要自己私下近行學習和查閱相關資料，畢竟自己知識眼界太低，我們要把微服務的理念執行下去，畢竟是未來的主流。給作者點贊，需要在重溫一把！溫故而知新，學而不思則罔，思而不學則殆

這本書cool哦！介紹的微服務框架，整理如下以供參考： 1.服務註冊中心service register，比如，zookeeper。 springcloud， netflix，Eureka。 2.服務調用方式, RPC, rest API。服務間通過REST api相互通信。 3.服務網關。gateway，負責分發路由，負載均衡策略，鑑權等。客戶端不會直接request服務端，要經過網關層！ 4.斷路器。很主要，類似熔斷機制。 5.分佈式配置config。 6.服務追蹤，也是鏈路追蹤。 7.消息總線bus。 8.數據流cloud stream。 9.批量任務cloud task. 以上不是業務拆分，是微服務框架分佈式分層解耦後的架構層級。對於不同業務拆分的規則是儘可能做到最大限度的松耦合。書中有提到模塊間的界限劃分！但是我還不太理解！他還沒有結合具體業務場景相關，進行深入探討！

《微服務設計》Building Microservices 在人工智能/AI之外，微服務是另一個火熱的領域。微服務就是一些小而自治的服務，其主要好處包括技術異構性、彈性、擴展、簡化部署、與組織結構相匹配和可組合性等。微服務架構是SOA (Service-Oriented Architecture)的進一步發展，是一系列原則，例如圍繞業務建模、去中心化、自動化等等，也是與一系列的技術緊密相關的包括雲計算、DevOps、持續集成(Continuous Integration)/持續部署(Continuous Delivery)、容器(Container)等。 在之前的項目中，當時雖然還沒有微服務的概念，但我們爲了優化系統嘗試了許多這個方向的事情，包括對功能的解耦合、異步架構、使用REST/JSON接口、各種緩存從CDN到varnish到memcache 、SSO(Single Sign On)、自動化測試、自動化部署、虛擬化/公有云、監控、安全等等等等。遇到了很多問題，取得了一些成績，學到了很多東西。 簡而言之，微服務設計是好東西，但也會帶來很多挑戰。IT技術的變化是日新月異的，微服務設計的這些思想理念和技術是一個旅程，關鍵是如何持續地改進和演變系統。而這本書作爲微服務的入門書籍，是超級推薦的。

企業的技術主管，在構建技術架構時必須擁有微服務設計的技能，而要設計出一套卓越的微服務架構，仍需充足的知識積累和實踐歷練。此書勾勒了一幅極佳的藍圖，但具體實施仍需依據實際狀況來做出抉擇。 編程語言、微服務架構框架、服務之間的調用機制、分佈式事務處理、一致性保障策略、負載均衡技術、部署策略……

微服務其實是服務撞上天花板的回應。在某種程度上，傳統的單體應用架構沒有伸縮性，數據庫變得太大了，有太多的代碼行，無法快速添加功能和特性，但微服務架構也帶來了一系列難以解決的新問題，特別是在日誌、監視、測試和調試應用程序方面。評估是否使用微服務應該考慮應用程序的生命週期，團隊的人數，還有業務的模塊是否需要拆分

偏向理論，最後引用書中的一段話:學會擁抱演進式架構的概念，在這種概念下，系統會在你學到一些新東西之後擴展和變化。不要去想大爆炸式的重寫，取而代之的是隨着時間的推移，逐步對系統進行一系列更改，這樣做可以保持系統的靈活性。