資訊專欄INFORMATION COLUMN
摘要：服務監控一旦服務消費者與服務提供者之間能夠正常發起服務調用，你就需要對調用情況進行監控，以了解服務是否正常。
目錄
一、微服務
1、服務化拆分的兩種姿勢
2、服務化拆分的前置條件
二、微服務組件
1、服務描述
2、注冊中心
3、服務框架
4、服務監控
5、服務追蹤
6、服務治理
微服務微服務架構是一種將單應用程序作為一套微型服務開發的方法，每種應用程序都在其自己的進程中運行，并與輕量級機制（通常是HTTP資源的API）進行通信。這些服務是圍繞業務功能構建的，可以通過全自動部署機制進行獨立部署。這些微服務的將集中化管理部分降到最少，同時，微服務還可以用不同的編程語言編寫，并使用不同的數據存儲技術。
服務化拆分的兩種姿勢
縱向拆分：從業務維度進行拆分。標準是按照業務的關聯程度來決定，關聯比較密切的業務適合拆分為一個微服務，而功能相對比較獨立的業務適合多帶帶拆分為一個微服務。
橫向拆分：從公共且獨立功能維度拆分。標準是按照是否有公共的被多個其他服務調用，且依賴的資源獨立不與其他業務耦合。
服務化拆分的前置條件
服務如何定義。對于單體應用來說，不同功能模塊之前相互交互時，通常是以類庫的方式來提供各個模塊的功能。對于微服務來說，每個服務都運行在各自的進程之中，應該以何種形式向外界傳達自己的信息呢？答案就是接口，無論采用哪種通訊協議，是HTTP還是RPC，服務之間的調用都通過接口描述來約定，約定內容包括接口名、接口參數以及接口返回值。
服務如何發布和訂閱。單體應用由于部署在同一個WAR包里，接口之間的調用屬于進程內的調用。而拆分為微服務獨立部署后，服務提供者該如何對外暴露自己的地址，服務調用者該如何查詢所需要調用的服務的地址呢？這個時候你就需要一個類似登記處的地方，能夠記錄每個服務提供者的地址以供服務調用者查詢，在微服務架構里，這個地方就是注冊中心。
服務如何監控。通常對于一個服務，我們最關心的是QPS（調用量）、AvgTime（平均耗時）以及P999（99.9%的請求性能在多少毫秒以內）這些指標。這時候你就需要一種通用的監控方案，能夠覆蓋業務埋點、數據收集、數據處理，最后到數據展示的全鏈路功能。
服務如何治理。可以想象，拆分為微服務架構后，服務的數量變多了，依賴關系也變復雜了。比如一個服務的性能有問題時，依賴的服務都勢必會受到影響。可以設定一個調用性能閾值，如果一段時間內一直超過這個值，那么依賴服務的調用可以直接返回，這就是熔斷，也是服務治理最常用的手段之一。
故障如何定位。在單體應用拆分為微服務之后，一次用戶調用可能依賴多個服務，每個服務又部署在不同的節點上，如果用戶調用出現問題，你需要有一種解決方案能夠將一次用戶請求進行標記，并在多個依賴的服務系統中繼續傳遞，以便串聯所有路徑，從而進行故障定位。
微服務組件服務描述
服務調用首先要解決的問題就是服務如何對外描述。比如，你對外提供了一個服務，那么這個服務的服務名叫什么？調用這個服務需要提供哪些信息？調用這個服務返回的結果是什么格式的？該如何解析？這些就是服務描述要解決的問題。簡單來說就是接口文檔。
常用的服務描述方式包括RESTful API、XML配置以及IDL文件三種。
注冊中心
你提供了一個服務，如何讓外部想調用你的服務的人知道。這個時候就需要一個類似注冊中心的角色，服務提供者將自己提供的服務以及地址登記到注冊中心，服務消費者則從注冊中心查詢所需要調用的服務的地址，然后發起請求。
服務框架
服務通信采用什么協議？就是說服務提供者和服務消費者之間以什么樣的協議進行網絡通信，是采用四層TCP、UDP協議，還是采用七層HTTP協議，還是采用其他協議？
數據傳輸采用什么方式？就是說服務提供者和服務消費者之間的數據傳輸采用哪種方式，是同步還是異步，是在單連接上傳輸，還是多路復用。
數據壓縮采用什么格式？通常數據傳輸都會對數據進行壓縮，來減少網絡傳輸的數據量，從而減少帶寬消耗和網絡傳輸時間，比如常見的JSON序列化、Java對象序列化以及Protobuf序列化等。
服務監控
一旦服務消費者與服務提供者之間能夠正常發起服務調用，你就需要對調用情況進行監控，以了解服務是否正常。
服務追蹤
你還需要記錄服務調用經過的每一層鏈路，以便進行問題追蹤和故障定位。
服務治理
服務監控能夠發現問題，服務追蹤能夠定位問題所在，而解決問題就得靠服務治理了。服務治理就是通過一系列的手段來保證在各種意外情況下，服務調用仍然能夠正常進行。比如自動擴縮容，就可以用來解決服務的容量問題。
感謝您耐心看完的文章
順便給大家推薦一個Java技術交流群：710373545里面會分享一些資深架構師錄制的視頻資料：有Spring，MyBatis，Netty源碼分析，高并發、高性能、分布式、微服務架構的原理，JVM性能優化、分布式架構等這些成為架構師必備的知識體系。還能領取免費的學習資源，目前受益良多！
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/74637.html
摘要：筆者對微服務系統的觀點是，我們從單體系統向微服務系統改造的過程中，需要認真思考什么階段使用微服務。此外，為了解決服務部署，我們可以考慮通過滾動發布來實現服務的無中斷。事實上，微服務保證其服務的整體可用性。 原文地址：梁桂釗的博客博客地址：http://blog.720ui.com 歡迎關注公眾號：「服務端思維」。一群同頻者，一起成長，一起精進，打破認知的局限性。 一、逃離單體系統，...
摘要：第二種則由多個小單元構成，每個小單元都是獨立的服務。微服務架構所依賴的彈性通信輕量等需求容器恰好可以完美提供，因此微服務與容器可以說是完美的一對。談到架構，微服務架構已然是時至今日必聊的一個話題，系統架構的選型與是否轉型，不應該是為了微服務架構而架構，而是源于微服務架構自身是否更適合業務自身的需求，微服務架構的優勢與所要付出的代價是否值得你，去做一次轉變。 ? ?GIStack for M...
摘要：降級往往會指定不同的級別，面臨不同的異常等級執行不同的處理。談談你對和的認識兩者關系具體可以看公眾號阿里巴巴中間件的這篇文章獨家解讀從微服務框架到微服務生態與并不是競爭關系，作為成熟的框架，其易用性擴展性和健壯性已得到業界的認可。 該文已加入筆主的開源項目——JavaGuide（一份涵蓋大部分Java程序員所需要掌握的核心知識的文檔類項目),地址:https://github.com/...
摘要：降級往往會指定不同的級別，面臨不同的異常等級執行不同的處理。談談你對和的認識兩者關系具體可以看公眾號阿里巴巴中間件的這篇文章獨家解讀從微服務框架到微服務生態與并不是競爭關系，作為成熟的框架，其易用性擴展性和健壯性已得到業界的認可。 該文已加入筆主的開源項目——JavaGuide（一份涵蓋大部分Java程序員所需要掌握的核心知識的文檔類項目),地址:https://github.com/...
閱讀 2115·2023-04-26 00:50
閱讀 2485·2021-10-13 09:39
閱讀 2217·2021-09-22 15:34
閱讀 1611·2021-09-04 16:41
閱讀 1340·2019-08-30 15:55
閱讀 2439·2019-08-30 15:53
閱讀 1712·2019-08-30 15:52
閱讀 752·2019-08-29 16:19
