架构与微服务本质论
為應對如今無線優先和全渠道用戶體驗的需求和挑戰，我們該如何設計靈活的面向體驗的微服務架構？它有哪些模式和最佳實踐？攜程，Netflix和SoundCloud這些知名互聯網公司是如何實踐面向體驗的微服務架構的？在過去的時間里，大牛馬丁福勒對微服務有哪些新的觀點？
微服務各家玩法不盡相同，我發現一些術語的叫法各公司也是不同的，可以說微服務目前仍在激烈的演化中，這個領域還未成熟和標準化，所以今天的分享主要是我個人的視角和總結，目的是拋磚引玉，激發大家進一步探索和實踐。
本次分享的主題包括：
微服務架構原理
用戶體驗適配層（Backend For Frontend）
攜程無線微服務案例分享
Netflix微服務架構分析
SoundCloud微服務架構分析
微服務架構不是免費的午餐
總結
本次分享也是應架構群內一些朋友的要求，將之前零散分享的內容總結成文，本次分享過程中會貼出相關內容參考鏈接（其中有些來自SlideShare和Netflix techblog的鏈接需要FQ訪問），供有興趣的朋友進一步學習。
一、微服務架構原理
微服務是個新概念，但它沒有一個明確的定義，各家對微服務的描述不盡相同，本人更傾向于用一些架構原理來描述它，因為架構原理是相對抽象和穩定的，而具體實現可以千差萬別。微服務原理和軟件工程，面向對象設計中的基本原理相通，體現如下：
單一職責（Single Responsibility），一個服務應當承擔盡可能單一的職責，服務應基于有界的上下文（bounded context，通常是邊界清晰的業務領域）構建，服務理想應當只有一個變更的理由（類似Robert C. Martin講的：A class should have only one reason to change），當一個服務承擔過多職責，就會產生各種耦合性問題，需要進一步拆分使其盡可能職責單一化。
關注分離（Separation of Concerns），跨橫切面邏輯，例如日志分析、監控、限流、安全等等，盡可能與具體的業務邏輯相互分離，讓開發人員能專注于業務邏輯的開發，減輕他們的思考負擔，這個也是有界上下文（bounded context）的一個體現。
模塊化（Modularity）和分而治之（Divide & Conquer），這個是解決復雜性問題的一般性方法，將大問題（如單塊架構）大而化小（模塊化和微服務化），然后分而治之。
微服務架構同時還是一個組織原理的體現，這個原理就是康威定律（Conway’s Law），Melvin Conway在1968年指出：“Any organization that design a system(defined broadly) will produce a design whose structure is a copy of the organization’s communication structure”，翻譯成中文就是：設計系統的組織，其產生的設計和架構等價于組織間的溝通結構。Dan North對此還補充說：“Those system then constrain the options for organization change”，簡言之，這些系統在建成之后反過來還會約束和限制組織的改變。下面兩個圖進一步解釋了這一組織原理：
Fig 1，團隊結構和系統架構不匹配
一般企業剛起步時，業務規模小，開發團隊規模也小，所以通常開發出來的系統是單塊的；隨著業務的擴大，團隊規模也會隨之擴大，這個時候多團隊組織架構和單塊系統架構之間就會產生不匹配問題（溝通協調成本增加，交付效率低下等等），如果不對單塊架構進行解耦和調整以適應新的團隊溝通結構，就會制約組織生產力和創新速度。
Fig 2，團隊結構和系統架構匹配
把單塊架構按照業務和團隊邊界進行拆分，重新調整為模塊化分散式架構（微服務架構是一種方案），那么組織團隊溝通結構和系統架構之間又能匹配起來，各個團隊才能夠獨立自治地演化各自的子系統（微服務），這種架構的解耦和調整可以解放組織生產力和提升創新速度。
二、用戶體驗適配層（Backend For Frontend）
眾所周知，隨著無線技術的發展和各種智能設備的興起，互聯網應用已經從單一Web瀏覽器時代演進到以API驅動的無線優先（Mobile First）和面向全渠道體驗（omni-channel experience oriented）的時代，如下圖所示：
Fig 3，從單一網站到API驅動的全渠道體驗
應用架構的新挑戰是：
用戶接入形式的多樣性，無線（手機、Pad），Web，互聯網電視，第三方合作應用等等，各種用戶設備的屏幕大小，操控體驗方式各不相同，例如，手機設備的屏幕較小，能夠展示的數據量小，交互方式以觸控為主，也可通過條形碼掃描器；
有些用戶設備的帶寬受限，同時應用的UI一般宿主在客戶端，有些頁面需要組合好幾個后臺業務服務的數據和功能，如果直接在客戶端發起對多個后臺服務的調用，勢必造成大量網絡開銷影響性能，這個有點類似數據庫查詢中的n+1問題。
BFF（Backend For Frontend）是應對上述應用架構挑戰的一種模式和最佳實踐，2015年底，ThoughtWorks在其網站上刊登了一篇稱為BFF@SoundCloud（SoundCloud是一個類似音頻YouTube的網站）的文章[附錄1]，講述SoundCloud如何利用BFF模式逐步將其單塊Rails應用遷移改造為支持無線等多種用戶體驗的微服務架構。同期，ThoughtWorks的顧問Sam Newman，也就是《Building Microservices》那本書的作者，在SoundCloud等業界實踐的基礎上，寫了一篇博客總結了BFF模式的原理、場景和用法[附錄2]，建議大家閱讀。
BFF本質上是一個后端中間層，但是它的作用主要是適配前端不同用戶體驗（無線，桌面，智能終端等等），所以稱為用戶體驗適配層，它的適配作用主要是：
裁剪和格式化，對后臺的通用數據模型進行適當的裁剪和格式化，以適應不同的用戶體驗展示的需要；
聚合編排，對后臺服務數據進行編排和預聚合，這樣可以有效簡化客戶端邏輯和減少網絡調用開銷。
下圖展示了一個無線BFF：
Sam推薦理想情況下針對每種用戶體驗類型需要一個BFF（one BFF per user experience），例如Mobile BFF，Desktop BFF，這可以做到職責單一和關注分離（遵循有界上下文原則），但是BFF過多也會造成代碼邏輯重復冗余的問題，需要權衡。UI和BFF理想是同一個團隊負責，這樣可以減少溝通協調成本，加快變更迭代速度，這是遵循康威定律的體現。下圖展示了一種BFF和團隊職責邊界劃分方案。
Sam還指出，對于一些跨橫切面的關注點（cross cutting concerns），例如路由，安全認證，日志監控分析，限流等等，通?？捎瑟毩⒌木W關（Gateway）層負責（如Fig 6所示），由獨立基礎設施團隊運維，置于BFF之前，這樣在架構上可以做到職責單一和關注分離，讓BFF開發人員專注于聚合裁剪等業務功能，無需考慮跨橫切面功能。但是如果對運維成本和調用性能有額外考慮，跨橫切面的功能也可以直接做在BFF一層。
Fig 6，獨立網關層負責跨橫切面功能
三、攜程無線微服務案例分享
攜程網是一家旅游行業的互聯網公司，其內部有約十幾個大小不同的事業部（也稱戰略事業單位，Strategic Business Unit，SBU）組成，例如機票，酒店，度假等等。三四年前，為迎合無線互聯網的趨勢，和很多其它互聯網公司一樣，公司成立了一個獨立的無線事業部（也是一個SBU），統一為整個公司開發無線應用。下面兩個圖分別是攜程無線H5應用的首頁（Fig 7），和最初的無線架構（Fig 8）：
Fig 7，攜程無線H5首頁
Fig 8，最初的攜程無線架構
架構底層是企業傳統的SOA/ESB/DB服務，架構上層是用戶的無線設備，中間是用戶體驗適配層BFF。攜程針對兩類不同的用戶體驗分別做了兩個BFF：
Mobile App BFF： 針對iOS，Android等Native和Hybrid應用場景，采用定制的TCP協議和二進制消息以提升網絡傳輸性能，
H5 BFF：針對HTML5瀏覽器應用場景，采用標準REST/JSON協議通訊。
最初，攜程無線BFF是單塊的（Monolithic），BFF由無線事業部集中開發，涵蓋其它所有SBU（酒店、機票、度假等）的聚合裁剪邏輯。剛開始，攜程無線應用相對簡單，單塊BFF有優勢，例如開發、測試和部署集中簡單，運維和集群擴容也比較方便。
但是隨著時間的推移，特別是近兩年，使用無線應用的用戶數成倍增長，無線應用的功能也變得越來越復雜，康威定律逐漸發揮作用，無線SBU和其它業務SBU之間的溝通協調成本越來越高，相互之間還常常因溝通不暢而產生摩擦，交付效率越來越低。同時，單塊BFF還具有代碼邏輯耦合臃腫，集群故障概率高，技術棧綁死，阻礙快速創新等單塊架構固有的缺陷。
2014年，攜程對組織架構進行了一次調整，將原無線事業部拆分，將無線團隊打散并安排到各個SBU業務事業部中。為配合組織架構的調整，公司的技術架構團隊也將原來的單塊BFF架構升級到如下的（Fig 9）面向體驗的微服務架構：
新架構中，原來的單塊BFF被拆分到各個SBU獨立開發、測試、部署和運維。新架構中引入了一個API網關層（API Gateway），是服務解耦自治的關鍵，主要負責服務反向路由，同時負責限流容錯、安全、日志、監控等跨橫切面的公共邏輯。BFF解耦之后，攜程微服務架構和組織業務架構進一步對齊，職責更明確，交付效率和創新速度明顯加快。
四、Netflix微服務架構分析
Netflix是一家美國的在線影像租賃服務提供商，早在2012-2013年左右，Netflix就已經建立起了比較成熟的微服務架構體系。值得一提的是，Netflix還把它的整個微服務技術棧開源出來貢獻給了社區，參考[附錄3]，其中包括知名的開源服務網關Zuul，服務注冊發現框架Eureka，服務端框架Karyon，客戶端框架Ribbon，容錯組件Hystrix等等，可以說Netflix對微服務架構的發展起了重要的推動作用。下圖展示了Netflix的微服務技術棧，來自Netflix參考應用rss reader[附錄10]，其中帶粉紅色標注的組件和Zuul都是開源的：
下圖是我對Netflix微服務技術棧的一個簡化和抽象，可見整個微服務體系的骨架：
Netflix的微服務體系可以簡化為兩層服務：
邊界服務層（Edge Service Layer），本質上就是BFF，適配前端各種用戶體驗的API層，
中間層服務（Middle Tier Service），Netflix后端的各種微服務的統稱。
Netflix的微服務體系由兩個重要的基礎設施支撐：
服務網關（API Gateway），是Netflix微服務的總入口，負責反向路由，安全，限流容錯，日志監控等跨橫切面的功能，
服務注冊表（Service Registry），負責網關到邊界服務，邊界服務到中間層服務，以及后臺服務之間的軟路由和軟負載。
關于Netflix微服務和API架構的更多內容，推薦參考SlideShare上的兩個ppt：
Transforming the Netflix API[附錄12]
Netflix’s Global Edge Architecture[附錄13]
下面的一些圖片是從上面兩個ppt中截取出來的。
Netflix需要針對超過一千種的設備提供服務，這對他們的API層（也就是邊界服務層或者BFF層）的設計提出了很大的挑戰，為了應對這種挑戰，Netflix的UI團隊和API團隊通力協作，由API團隊提供通用的API運行時平臺（有點類似PaaS for API的概念），UI團隊則在API運行時平臺上針對不同設備利用動態腳本開發不同的API端點，這種模式最大化了UI團隊的效率和靈活性，如下圖所示：
Fig 12，UI和API團隊協同開發API
Netflix的API運行時平臺內部細節和運作方式如下圖所示：
Fig 13，動態腳本平臺
Netflix的API運行時平臺由API團隊負責開發和運維，其中內置支持：
通用的調用后臺服務的SDK；
支持并發調用多個后臺服務的異步服務層（基于RxJava）；
容錯組件Hystrix。
UI工程師利用Groovy腳本根據前端設備展示的需要開發API腳本，通過SDK調用后臺服務，對后臺服務和數據進行聚合裁剪，開發完成的腳本通過端點管理器上傳到API運行時平臺上，最后激活該腳本則對應的API端點就能生效對外提供服務。Netflix API運行時平臺也稱為動態腳本平臺（Dynamic Scripting Platform），更多細節可參考[附錄4]和[附錄11]。
Netflix應用采用前后分離架構，頁面等靜態資源置于CDN上，用戶設備從CDN直接加載頁面，交互時頁面直接從后臺邊界服務層獲取數據，如下圖所示：
下圖是Netflix API在AWS上的部署架構:
注：最新的Netflix開源項目Falcor[附錄5]表明Netflix同時也采用基于Node/JS技術的裁剪適配層，目的是給前端UI團隊更大靈活性和自主權。Facebook有一個類似的項目GraphQL[附錄16]。
五、SoundCloud微服務架構分析
SoundCloud是一家音頻分享網站，有點類似音頻界的YouTube，最近SoundCloud在SlideShare上分享了他們的微服務架構和實踐。
Fig 16，SoundCloud微服務架構一
上圖是從SoundCloud的一個ppt截取的微服務層次結構圖，和Netflix/攜程類似，兩個主要層次是：
邊界服務層（Edge Layer），相當于BFF，針對不同場景體驗的適配層，例如第三方集成的Public API，嵌入頁面場景的Api-embedded，無線場景的Api-mobile和桌面應用場景的Api-v2。
微服務層（Microservices），SoundCloud后臺微服務的統稱，例如messages、stats、likes服務等等。
下圖是從SoundCloud另一個PPT截取的微服務架構圖。
Fig 17，SoundCloud微服務架構二
有兩點值得關注：
SoundCloud將Geoip、限流、安全認證等跨橫切面功能和BFF做在同一層，沒有像Netflix/攜程一樣做在獨立的網關層，SoundCloud的這一做法有性能優勢，但同時也增加了BFF層的復雜性；
SoundCloud將后臺微服務又分為兩層，最底層的基礎服務層（Foundation Service Layer）和中間的增值服務層（Value-added Service Layer），這種分層方式是SoundCloud根據自己的需要提出的一種邏輯劃分。
關于SoundCloud微服務架構的更多內容，請參考SlideShare上的兩個PPT：
BFF Pattern in Action: SoundCloud’s Microservices[附錄14]
Microservices@SoundCloud[附錄15]
六、微服務架構不是免費的午餐
上面分享的三家公司都是體量比較大的互聯網公司，他們的業務量和團隊規模決定他們很難不采用微服務架構，但是對中小型規模的公司來說，這三家的架構未必是可以直接照搬的，個人認為，解決問題的scope不同，所采用的架構一般也不同，不能盲目照搬。
在業界對微服務架構熱情高漲之際，馬丁福勒在2015年陸續寫了幾篇文章，讓人們更客觀理性地看待微服務，建議大家進一步閱讀：
微服務架構先決條件[附錄7]
馬丁說，你必須長足夠高，才可以考慮使用微服務，這里的高就是指基本的研發能力，包括：
快速的環境提供（Rapid Provisioning）能力，理想有基于云的環境提供能力。
基本的監控 (Basic Monitoring）能力。
快速的應用發布（Rapid Application Deployment）能力。
DevOps文化。
在沒有建立起這些能力之前，勿輕易跟風采用微服務架構，上面分享的三家公司，都是在具備這些基礎研發能力的基礎上才開展微服務的。
微服務的附加成本[附錄8]
馬丁指出，當業務不復雜，團隊規模不大的時候，單塊架構比微服務架構具有更高的生產率（productivity），原因在于建立微服務架構需要額外的開銷來支持和管理微服務，從而降低生產率；但是隨著業務復雜性的增加和團隊規模的擴大，單塊架構比微服務架構的生產率下降更趨明顯，當復雜性達到一個點，微服務架構的生產率會優于單塊架構，原因在于微服務的松散耦合自治特性減緩了生產率的下降趨勢。
注：馬丁在上圖的右下角提出了一個很有意思的觀點，團隊的技能是比單塊或者微服務架構的選擇更重要的因素。說白了，如果團隊能力不行，不管用單塊還是微服務，還是難于管理復雜性。
反過來，如果團隊能力強，不管用單塊還是微服務，都能找到好的管理復雜性的手段，所以說團隊的技能才是管理復雜性的關鍵。
單塊優先(Monolith First)[附錄9]
馬丁說，他不建議企業應用一開始就直接上微服務架構，原因一方面是支持微服務架構需要額外的開銷來管理分布式復雜性，另一方面是剛開始系統復雜度和領域邊界是不清晰的，你不知道該如何正確的切分微服務，所以這種方案常常具有很高的失敗風險。
馬丁建議企業應用走單塊優先的架構思路，先輕裝上陣，贏得時間探索系統的復雜性和領域邊界，當復雜性增加時，拆出部分微服務，隨著團隊對服務邊界更加清晰和服務管理能力的提升，持續拆分出更多微服務，最終演化出微服務架構。
上面分享的案例中，像攜程/SoundCloud都是從單塊架構起步，隨著業務和團隊規模的增長不斷調整其架構，最終演化出微服務架構，SoundCloud從單塊到微服務演化經歷可參考[附錄1]。
七、總結
1、微服務架構是一種支持演化的自適應的架構，微服務架構本身也是演化的結果，架構演化的主要驅動因子是：
經濟達爾文：從長遠看，只有那些能更好滿足客戶需求的企業才能生存。簡單講就是業務驅動，業務要求架構靈活易于變更和擴展，易于升級替換，發布快速，高可用能應對不可預測的流量模式，能支持多樣的用戶設備和體驗，這樣才能加快業務創新的速度，贏得客戶和競爭優勢；
無線、智能設備和云等技術的進步和發展；
康威定律，即企業的業務、組織和系統邊界要盡可能對齊，以業務領域和微服務為邊界的產品型跨職能團隊能更敏捷地響應市場需求。
2、系統架構的首要目標是管理復雜性，遵循良好的架構原理，如單一職責、有界上下文、關注分離、模塊化和分而治之，是管理復雜性的有效手段。在企業應用成長到一定規模以后，微服務架構是管理復雜性的一種行之有效的架構風格。
3、企業要不要用微服務，取決于你的業務復雜度和團隊規模，一般Monolith First。業界大型互聯網企業的微服務架構可以參考和學習，但是不能照搬，解決問題的scope不同，采用的架構也不同。
4、BFF（Backend For Frontend）是應對當前多種用戶體驗的一種模式和最佳實踐，BFF的主要作用是針對不同的用戶體驗對后臺服務和數據做聚合裁剪適配。用戶體驗適配層，BFF，API Orchestration Layer，Edge Service Layer，Device Wrapper Layer是相似概念。
5、Client -> API Gateway -> BFF -> Downstream Microservices，是面向體驗的微服務的標準參考架構。
6、2016年的參考應用架構如下圖所示，引用自ThoughtWorks的文章<技術棧復雜度飆升給管理者們的啟示>>[附錄6]，特點：
企業后臺采用微服務架構，微服務可以采用不同的編程語言和不同的存儲機制；
企業前臺采用BFF模式對不同的用戶體驗（如桌面瀏覽器，Native App，平板響應式Web）進行適配；
企業后臺采集各種數據，集中存儲，再進行大數據建模、分析和預測，計算出來的數據再以微服務方式反哺給前臺頁面（例如商品推薦）。
附錄
很多不錯的文章，有興趣的同學可以參與翻譯。
1、BFF@SoundCloud https://www.thoughtworks.com/insights/blog/bff-soundcloud
2、Pattern: Backends For Frontends http://samnewman.io/patterns/architectural/bff/
3、Netflix Open Source Software Center http://netflix.github.io/
4、Netflix Dynamic Scripting Platform http://techblog.netflix.com/2014/03/the-netflix-dynamic-scripting-platform.html
5、Falcor, A Javascript library for efficient data fetching https://github.com/Netflix/falcor
6、技術棧復雜度飆升給管理者們的啟示 http://www.neucloud.cn/article/1399_The-inspiration-of-the-technology-stack-complexity-surge-to-managers.html
7、微服務架構先決條件 http://martinfowler.com/bliki/MicroservicePrerequisites.html
8、微服務的附加成本 http://martinfowler.com/bliki/MicroservicePremium.html
9、單塊優先（Monolith First） http://martinfowler.com/bliki/MonolithFirst.html
10、Introducing the first NetflixOSS Recipe: RSS Reader http://techblog.netflix.com/2013/03/introducing-first-netflixoss-recipe-rss.html
11、Optimizing the Netflix API http://techblog.netflix.com/2013/01/optimizing-netflix-api.html
12、Transforming the Netflix API http://www.slideshare.net/benjaminschmaus/bschmaus-apiworldtransformingnetflixapi
13、Netflix’s Global Edge Architecture http://www.slideshare.net/MikeyCohen1/edge-architecture-ieee-international-conference-on-cloud-engineering-32240146
14、BFF Pattern in Action: SoundCloud’s Microservices http://www.slideshare.net/grandbora/bff-pattern-in-action-soundclouds-microservices
15、Microservices @ SoundCloud http://www.slideshare.net/grandbora/microservices-soundcloud
16、GraphQL A data query language and runtime http://graphql.org/
互動問答
問題：微服務與SOA的區別是什么？
我覺得兩者體現相通的架構原理：單一職責，有界上下文，關注分離，分而治之。區別在于微服務粒度更細，同時融入了近幾年一線互聯網公司的一些最佳實踐，是服務化的新提法。
問題：API網關的反向路由的設計思路能具體說明一下嗎？
攜程的API網關基于Netflix的Zuul開源組件。對外暴露一個域名api.ctrip.com，根據第一級目錄做反向路由。
api.ctrip.com/hotel，api.ctrip.com/flight，api.ctrip.com/vacation。每一級目錄，如hotel, flight, vacation對應一個后端BFF集群的域名，也就是說Gateway里頭有一張映射表，這張表示是可以動態配置的，可以動態路由，灰度，藍綠部署都可以通過這張映射表做出來。
問題：分布式數據一致性問題在實踐中是怎么解決的？最終一致性方案中的event-driven和event sourcing或其他方案實踐中是怎么選型的？有沒有推薦的參考框架或方案？
event-driven和event sourcing是Chris Richardson推崇的，他最近還到DaoCloud做演講。推薦閱讀：
微服務系列之「事件驅動型微服務」
http://blog.daocloud.io/chris-richardson-1/
Chris Richardson 微服務系列之「事件溯源（Event Sourcing）型微服務」
http://blog.daocloud.io/chris-richardson-2/
Chris Richardson 微服務系列之「最佳實例：Eventuate」
http://blog.daocloud.io/chris-richardson-3/
Chris Richardson在他的GitHub上還做了一個event-sourcing的樣例，值得參考：
https://github.com/cer/event-sourcing-examples
我本人覺得還是復雜了，如果簡單場景實時性要求不高，簡單隊列訂閱解決分布式一致性問題。
問題：微服務的分布式事務該怎么做？如果做二次提交怎么處理回滾？
分布式事務盡量避免?！度绾斡孟⑾到y避免分布式事務？》這篇文章的方法簡單可以參考：http://www.cnblogs.com/LBSer/p/4715395.html
問題：微服務感覺就像是服務的模塊化，那么如果我一個業務需要多個服務那該在哪里調用這些服務，這么理解對嗎？
微服務本質就是模塊化，分布式模塊化。“如果我一個業務需要多個服務那該在哪里調用這些服務”：BFF，或者中間層的聚合編排服務。
問題：1、微服務架構下，數據庫該如何部署呢？有的說一定要每個服務單獨部署，有的說要服務共享數據庫，您的意見是怎樣的？ 2、服務在拆分，部署的時候有什么設計原則嗎？
1、要看情況，不能絕對的。2、拆分理想按照領域邊界，團隊邊界拆，這個也是不斷演化的。
問題：微服務如果變多了有什么辦法管理呢？極端點如果有一千個怎么辦？
我當時在eBay維護Trading API，也就是eBay最大的一個API，有差不多160多個API。這個維護成本已經很高了，也是跟eBay的體量相對應的。服務拆分到多細粒度，要根據具體情況的，原則雖然是職責單一，但也要看你的團隊和資源的限制。目前我所在公司40多號人維護一個網站，我估計最多也就拆出20~30個服務，再多維護不過來。原則是一種指導，但是具體實施要看上下文。
企業真的到了一定體量，按業務要求服務越來越多，Netflix內部微服務應該超過千個，阿里巴巴也超過千個，這個時候要靠基礎設施和自動化了，需要微服務基礎設施，監控，DevOps和持續交付平臺支撐成千上萬的微服務，我認為管理復雜性主要靠三個支柱：
1.基礎設施平臺自動化
2.人才密度
3.遵循好的架構原則和最佳實踐
最后給大家分享一些我自己收集的架構資料，關注我，私信發送“JAVA”即可獲取以下資料：
?
轉載于:https://www.cnblogs.com/lfs2640666960/p/8590535.html
與50位技術專家面對面20年技術見證，附贈技術全景圖總結
- 上一篇： DrawerLayout侧滑
- 下一篇： jQuery插件-json2.js