老鐵們，大家好，相信還有很多朋友對于常用的微服務架構和微服務架構和分布式架構的區別的相關問題不太懂，沒關系，今天就由我來為大家分享分享常用的微服務架構以及微服務架構和分布式架構的區別的問題，文章篇幅可能偏長，希望可以幫助到大家，下面一起來看看吧！
微服務框架排行
微服務架構的經典開發框架1,SpringCloud：最早最成熟，Java開源微服務框架方案2,Dubbo:阿里巴巴開源Java服務治理框架Spring3,3,CloudAlibaba阿里開源Java微服務框架方案
4,SOFA：螞蟻金服開源Java金融微服務框架方案GoMicro：
5,Go語言開源微服務框架。
微服務架構設計理念是什么
一、微服務架構
1.什么是微服務
??????微服務是一種架構風格，一個大型的復雜軟件應用，由一個或者多個微服務組成，系統中的各個微服務可以被獨立部署，各個微服務之間是松耦合的，每個微服務僅僅關注于完成一件任務并很好的完成該任務。將一個復雜的軟件系統，進行了慘無人道的拆分，但是通過拆分之后，這個復雜的應用系統變的更加的高效。
2.架構風格
??????所謂的架構風格就是項目的一種設計模式。而我們常見的程序設計模式有以下的四種方式。后面對于每個模式的優缺點進行了詳細的比較。
常見的架構風格
??????客戶端與服務器端：包括C/S和B/S兩種，而B/S比較特殊。
??????基于組件模型的架構（EJB）
??????分層架構（MVC）
??????面向服務架構（SOA）
3.微服務特點
??????（1）系統是有多個服務構成
??????（2）每個服務可以單獨獨立部署
??????（3）每個服務之間是松耦合的。服務內部是高內聚的，外部是低耦合的，也是比較符合軟件設計原則的，高內聚就是每個服務內部的關系是非常密切的，每個服務之間只關注完成一個功能。
4.微服務的優點、缺點
??????優點
??????測試容易
??????可伸縮性強
??????可靠性強
??????跨語言程度會更加靈活
??????團隊協作容易
??????系統迭代容易
??????缺點
??????運維成本過高，部署數量較多
??????接口兼容多版本
??????分布式系統的復雜性
??????分布式事務
二、如何設計微服務及其設計原則
??????1.AKF分拆原則
??????2.前端后端分離原則
??????3.無狀態服務
??????4.RestFul的通行風格
grpc微服務架構
1.是一種高效的微服務架構。2.因為gRPC采用了基于HTTP/2的傳輸協議，具有較低的延遲和高并發能力，同時支持多種編程語言，使得不同服務之間的通信更加方便快捷。此外，gRPC還支持多種序列化和反序列化機制，使得數據傳輸更加高效。3.gRPC的微服務架構可以幫助開發人員更好地實現服務之間的解耦和靈活性，同時提供了豐富的工具和庫來簡化開發過程。此外，gRPC還支持服務發現、負載均衡和故障恢復等功能，使得整個系統更加穩定可靠。通過使用gRPC，開發人員可以更加高效地構建和管理復雜的分布式系統。
微服務項目結構如何劃分
1微服務項目的結構可以劃分為三個部分：應用程序、服務和基礎設施。2應用程序是指提供實際業務價值的服務，可以包含多個微服務。服務是指執行特定任務的單個微服務，每個服務都有自己的職責和功能。基礎設施是指支持微服務架構的各種工具和框架，包括服務發現、負載均衡、日志管理等。3在微服務項目中，應該將應用程序和服務分離出來，使它們能夠獨立部署和擴展。同時，基礎設施應該被視為一個單獨的部分，以便更好地管理和維護。對于服務的劃分，應該根據業務邏輯和職責來進行，每個服務應該盡可能地獨立和自治。
系統軟件架構中，現在很流行微服務，那么使用微服務就一定好么微服務有哪些缺點呢
下面簡單回答下這個問題。在回答這個問題前還是先回顧下微服務架構。
微服務架構概述微服務架構本質是單個業務系統徹底的組件化（前端，邏輯層，數據庫）解耦，同時相互之間通過輕量的服務接口和協議進行協同。這和很早就談到的組件化架構思想是一致的，實現微服務架構后，你會看到沒有傳統業務系統的概念了，有的只是微服務模塊或小應用。微服務架構最近又炒的相當活，很多人會說SOA過時了，ESB過時了，甚至還有人用微服務架構去徹底的否定SOA和ESB，這些都是相當危險的信號。在我12，13年寫企業私有云PaaS平臺的一系列文章的時候，已經提出了業務能力組件化，組件服務化的微服務架構思想，但是實際應用實施效果并不太理想。
我們可以先看下從單體應用到微服務架構的變化圖。
把這個核心搞清楚后，再來看下網上找到的對微服務架構的一些定義和闡述：
微服務可以在“自己的程序”中運行，并通過“輕量級設備與HTTP型API進行溝通”。關鍵在于該服務可以在自己的程序中運行。通過這一點我們就可以將服務公開與微服務架構（在現有系統中分布一個API）區分開來。在服務公開中，許多服務都可以被內部獨立進程所限制。如果其中任何一個服務需要增加某種功能，那么就必須縮小進程范圍。在微服務架構中，只需要在特定的某種服務中增加所需功能，而不影響整體進程。微服務不需要像普通服務那樣成為一種獨立的功能或者獨立的資源。定義中稱，微服務是需要與業務能力相匹配，這種說法完全正確。不幸的是，仍然意味著，如果能力模型粒度的設計是錯誤的，那么，我們就必須付出很多代價。如果你閱讀了Fowler的整篇文章，你會發現，其中的指導建議是非常實用的。在決定將所有組件組合到一起時，開發人員需要非常確信這些組件都會有所改變，并且規模也會發生變化。服務粒度越粗，就越難以符合規定原則。服務粒度越細，就越能夠靈活地降低變化和負載所帶來的影響。然而，利弊之間的權衡過程是非常復雜的，我們要在配置和資金模型的基礎上考慮到基礎設施的成本問題。
在了解了微服務架構后，我們來分析下微服務架構又哪些缺點和難點。
微服務模塊拆分后，各微服務間集成復雜度指數級增加簡單舉例來說，一個企業已經實施了5個業務系統，業務系統之間有10個接口。如果全部微服務化則可能設計到50個微服務模塊，上100個接口和集成點。可想而知，在徹底實施微服務后，我們前期架構設計，后期集成和管控的復雜度增加10倍以上。這種集成難度會遠超大多數人想象，如果拿真實做的項目來說，如果談業務系統只有3個，而到微服務模塊級別則有接近60個，而實際涉及到的集成接口上1000個。我們做任何一個復雜端到端業務的聯調基本就需要花2，3周甚至更長的時間。互聯網企業為何適合做微服務架構，其重要的一個原因就是互聯網企業如電商平臺，在進行了微服務化后各個模塊之間耦合性很低，并不會有太多的集成和協同點。或者簡單來說，各個微服務模塊更多的是向上面的PC端或APP端提供服務能力，而模塊橫向間接口協同很少。正是在這種低耦合情況下，協同和集成相對來說容易。而轉回到企業內部你會發現，在微服務模塊化后，各個模塊之間的集成點相當多，特別是業務系統拆分到模塊或組件這一個級別后，很多原有內部的集成和依賴點全部暴露出來了，你都需要去很好的管理。由于這里面有大量的橫向集成和協同點，因此導致的就是微服務模塊間的橫向集成異常復雜，遠超很多互聯網應用，這是實際你會面臨的問題。
微服務模塊拆分后，各微服務間集成復雜度指數級增加只談微服務架構的松耦合和高擴展性，而不談開發和集成復雜度的都是耍流氓。實際上當前很多企業對微服務架構并沒有如此迫切，互聯網很多企業推行微服務架構更多的還是考慮到巨大的業務并發量下的系統彈性擴展能力，而實際大多數企業內應用往往并沒有如此海量并發。其次，即使在并發量增加的情況下通過進行代碼本身的優化，數據庫調優或者升級硬件服務器資源都可以較好的解決性能問題。而做這些事情投入的成本遠遠小于微服務架構帶來的開發復雜度增加成本，后期的運維管控成本。要做到完全微服務模塊獨立，微服務架構下最大的一個變化就是數據庫也拆分開了，原來的一個業務系統如果分為5個微服務模塊，那理論上就是5個獨立的后臺數據庫，而且數據庫間還不能隨便相互連接和訪問。只有這樣微服務模塊才能做到獨立部署和管理。由于數據庫拆分帶來兩個問題，其一是我們原來很簡單的一個跨表查詢操作現在無法做了，我們必須調用兩個微服務模塊提供的服務，查詢到數據后再到邏輯層進行組合。其次最大的問題就是如果一個業務操作需要同時更新兩個微服務模塊的數據，由于服務本身無狀態，導致了這種分布式事務問題很難解決。企業內業務系統很大一個特點就是業務邏輯和規則相對互聯網更加復雜，而且有更高的事務一致性要求。正是由于這個原因，無法解決好分布式事務的問題都將直接導致后續數據不一致和業務錯誤。原來通過調用項目內一個API方法就能解決的問題，現在要調用遠程WS接口才能解決，這本身就增加了開發和調試的復雜度。一個微服務模塊與外部其它模塊的集成和協同越少，你會發現該微服務模塊和傳統業務系統開發沒太大區別，但是當其涉及到完成任何一個功能都需要調用外部微服務模塊的服務接口時候，其開發模式和效率上就會帶來巨大的變化。
微服務架構下運維難度增加在實施了微服務架構后，運維的復雜度也是成倍增加，任何一個微服務模塊出問題都可能影響到整個業務應用的功能使用。我們在運維時候不僅僅要健康單個微服務模塊，還需要健康所有的接口服務監控狀態。如果跟Docker集成了，我們看到整個性能監控和問題分析都會變麻煩了，沒有實施微服務架構前發現問題，我們直接可以看應用服務器上類似tomcat或jboss日志，而實施了微服務架構后，應用容器已經是自動部署和動態分配的，原有的故障診斷模式行不通，而需要PaaS平臺本身提供完整的預警和日志分析能力。再次，如果發現了性能問題或故障，我們的解決方案是如何的？我們如何保證不影響到業務運行，不出現數據的丟失，或者在微服務模塊擴展的時候不出現業務中斷等。這些已經不是簡單的部署架構層面的冗余能解決的問題，而涉及到我們在整個微服務架構中的消息策略，事務管理機制，持久化機制等問題。
引入微服務后的實施難度增加一個企業所涉及到的IT開發和架構能力以及企業本身的IT治理管控成熟度都將直接影響到微服務架構能否實施成功，要知道引入微服務架構后集成和后續運維等的復雜度都會成指數級增長。
方式1：引入的外部開發商進行微服務架構化如果一個企業本身IT部門規模小，軟件以外購為主，那么勢必在對ERP等各類軟件的選型評估后引入不同的軟件產品提供商或軟件開發商。那么軟件商本身都有了成熟的產品或架構，其產品內部的模塊是否符合組件化和微服務架構的要求，我們不得而知。即使招標要求寫明軟件提供商提供產品需要基于SOA或微服務參考架構，但是實際上由于企業本身的IT能力和水平往往也無法驗證，而對于軟件廠商來說一定希望是賣現有產品，減少改造和定制實現利潤的最大化。對于軟件開發廠商來說對已有的軟件產品是沒有微服務架構改造的動力的。那在這種情況下要推動微服務架構實施落地必須的就是企業本身有很強的架構管控能力和甲方話語權。在曾經實施的案例里面可以看到，甲方在有較強的IT規劃和架構設計能力情況下，才可能一開始就劃分好微服務模塊并且設計好微服務模塊間的接口，在進行招標和選型。同時甲方話語權強的情況下，可以完全要求軟件供應商按照自己定義好的標準，規范，架構進行微服務模塊的開發。簡單點來說頂層架構分解和接口設計能力不在單個微服務模塊開發商手里面，而是在甲方手里，或者在甲方請的專門負責規劃架構設計的技術咨詢團隊手里。在這種模式下，技術咨詢團隊應該對整體模塊劃分和后續集成負責，技術咨詢團隊就需要有業務和技術兩方面的能力，同時有類似領域的規劃設計經驗，系統開發建設經驗等。這些本身就對技術咨詢團隊提出了相當高的要求，可以來講很少有技術咨詢團隊達到這個水平，包括埃森哲或德勤等也難。在微服務架構下，我們希望的是一個業務系統如果由三個微服務模塊組成，在我們進行了前期的架構和接口設計后，我們完全可以將三個模塊發標給不同的軟件開發商建設和實施，然后在根據預先定義的服務接口進行集成。這個從理論上是行得通的，但是實際上出現兩個問題。其一是剛開始的模塊劃分或接口設計不合理，在后面開發過程中才發現又很難再大變更。其二是微服務模塊間的接口服務太多，導致了模塊間的集成和聯調異常復雜。從上面也看到引入微服務架構后，企業本身可以削弱單個軟件供應商對企業本身的約束，防止被單一廠商綁定。因此企業沒有特色要求，從軟件廠商來說沒有任何動力和意愿推微服務架構。方式2：企業自由開發團隊實踐微服務架構如果企業本身的IT成熟度沒有達到一定階段，顯然是不可能推行實施微服務架構的。這個道理前面已經談到過，在企業IT建設中，如果連粗粒度的業務系統以及它們之間的集成都管理不好，那么更沒有能力管理細粒度的微服務模塊。那么如果企業IT成熟度達到一定水平，在推廣微服務架構還存在的難點如下：首先是架構設計能力的顯性化，即架構設計這個工作的輸入，輸出和過程需要更加的顯性化出來形成團隊都認同的標準工件。一個業務系統沒有拆分開時候，雖然有架構設計和組件劃分，但是這個工作是屬于團隊內部的事情，即使架構設計不合理，在后期集成也可以通過諸多變通方式解決掉。而現在是不同的微服務模塊可能分派到兩個獨立的團隊開發，原來屬于自己內部黑盒的問題變為團隊間問題。簡單來說你原來藏著或沒做規范的東西太多，而現在這些不能再藏著掖著了，當真要把這些東西拿出來的時候，你才會發現你原來架構能力是有欠缺的。正如我們理解了一個東西，那么要讓我們清楚的講出來困難，那么我們的理解有欠缺。對于我們能講清楚的東西，要系統的寫下來有困難，那么說明我們講的結構和條理有欠缺。其次管控要求和規范體系的建立，對于管控要求可以看到如果兩個微服務模塊分給同一個團隊開發，如何才能保證開發的團隊保持兩個模塊的完全獨立和解耦，兩個模塊間不會出現相互交叉的數據庫直接調用，也不會存在直接繞開Service接口的其它耦合調用？這些如果沒有完整的管控和檢查體系我們很難約束。以上即是引入微服務架構后帶來的難點或缺點，供參考。自己也長期專注于SOA，微服務，DevOps支撐平臺建設實施，歡迎交流。
OK，本文到此結束，希望對大家有所幫助。
