架构演化：云原生时代开启之系列一演化篇
信息技術從出現伊始到漸成主流，其趨勢經歷了軟件、開源和云三個階段：
軟件改變世界。縱觀人類社會漫長的發展歷程，農耕時代、工業時代與信息時代可謂是三個明顯分水嶺，每個時代人類涉及的領域范疇均噴井式增長。作為信息時代最重要的載體，互聯網越來越成為當今社會關注的焦點，互聯網的基石之一，軟件正在迅速地改變著這個世界。
開源改變軟件。隨著軟件行業的積累與成熟，相比于重復制造輪子，站在巨人的肩膀上則更加容易和快速地創造出優秀的新產品。隨著開源文化的認可度越來越高，使用優秀的開源產品作為基礎構架，快速搭建系統以實現市場戰略是當今的最優資源配比方案。
云吞噬開源。對互聯網近乎100%可用性的需要，僅通過開源產品搭建并運維一個高可用、高度彈性化的平臺并非易事。因此，提供技術思路的同時，進一步提供整套云解決方案，以保障不斷擴展的非功能需求，是當今新一代互聯網平臺的追求。
在信息技術的大潮中，每一次通信的升級，都會對世界的合作模式產生改變。隨著互聯網在本世紀初大規模的接入，互聯網由基于流量點擊盈利的單方面信息發布門戶的web 1.0業務模式，轉變為了由用戶主導而生成內容的互聯網產品，即web 2.0業務模式。因此，互聯網應用系統所需處理的訪問量和數據量均急速增長，后端技術架構也因此面臨著巨大的挑戰。這一階段的互聯網后端架構大多由All in One的單體式應用架構漸漸的轉向為更加靈活的分布式應用架構；而企業級架構由于功能復雜，而且并未出現明顯的系統瓶頸，因而并未跟進。后端開發由單一技術棧漸漸區分開來，越來越明顯的劃分為企業級開發和互聯網開發。企業級開發和互聯網開發的差別不僅在于技術棧，也在于工作模式，對質量的追求與對效率的提升成為了兩個陣營的分水嶺。
??隨著智能手機出現以及4G信號的普及，互聯網應用由PC端迅速轉向更加自由的移動端，由于攜帶方便且便于定位，在出行、網購、付款等方面徹底了改變的現代人的生活方式。在技術方面，為了應對更加巨大的規模，單純的分布式系統已經難以駕馭。技術圈也因此契機開啟了一個概念爆發的時代，SOA、DevOps、容器、CI\CD、微服務、Service Mesh等概念層出不窮，而Docker、Kubernetes、Mesos、Spring Cloud、gRPC等一系列產品的出現，標志著云時代真正的到來。
云時代下的互聯網架構變遷
互聯網應用的業務特征決定它和企業級應用的諸多不同，主要有以下幾點：
1.海量用戶
互聯網應用幾乎無差別的服務于全世界所有的用戶，與服務于局域網用戶的企業級應用相比，它們的用戶量基數差距很大，由海量用戶產生的數據量也會成幾何級增長。
2.產品迭代迅速
隨著業務模式的快速拓展，互聯網應用功能推陳出新的速度越來越快。在當今如此快節奏的時代，時間成本非常關鍵。
3.7*24不間斷服務
互聯網應用作為一個面向全球的服務，時區的差異，使得應用必須保證全天隨時可用，每次宕機都會產生很大的損失。
4.流量突增
不同類型的互聯網公司有著各自不同的流量突增場景。比如，電商類公司會在雙十一這樣的大促期間流量突增幾倍、幾十倍甚至上百倍；社交類公司會在熱點事件爆發的時候流量突增。
5.業務組合復雜
很多互聯網公司都是跨界巨頭，即使并非跨界，在單一領域，編織一個大規模的成型業務也并不簡單。以電商行業舉例，在應用系統層面大致會劃分為賣場、交易、訂單、倉儲、物流等主流程系統；搜索、推薦、社區、會員、客服、退換貨等面向用戶的前端系統；商品、價格、庫存、配貨、促銷、供應鏈等面向后臺員工的后端系統；以及廣告、商家、支付、清算、財務、報表等面向合作伙伴的輔助系統。而每個應用系統又會劃分為很多子系統。一個粗略的電商系統業務架構圖：
由于互聯網行業業務特征的特殊性以及勢不可擋的擴張速度，相應的底層支撐的技術挑戰也越來越大，究其根本原因是其不斷擴張的規模。由規模而衍生的問題包括海量數據、響應遲緩、穩定性差、伸縮性差、系統繁多和開發困難等問題。
因此針對這些問題，互聯網的技術架構也在逐漸的轉變，以
集中式?–>分布式->?云平臺的方向演進。
從集中式到分布式架構
? ??集中式架構又叫單體式架構，在web2.0模式并未大規模興起時，十分流行。進入新世紀以來，基于web應用的B/S架構逐漸的取代了基于桌面應用的C/S架構。B/S架構的后端系統，大都采用集中式架構，它當時以優雅的分層設計，統一了服務器后端的開發領域。
1.傳統的三層架構模型
? ??在web 2.0剛開始流行的時候，互聯網應用與企業級應用并沒有本質的區別，集中式應用分為標準的3層架構模型：數據訪問層、服務層和邏輯控制層。每個層之間既可以共享領域模型對象，也可以做更加細致的拆分。
由于NoSQL在當時還并未興起，因此數據庫訪問層主要是關系型數據庫的訪問，出現了很多ORM框架。MyBatis及其前身IBatis、JPA以及它的默認實現Hibernate都是ORM領域中開源框架的翹楚。
服務層用于編寫應用的具體業務邏輯，它需要一個使用便捷且可以對數據訪問層和邏輯控制層能夠承前啟后的框架。Java官方所推薦的EJB 2.X過于笨重，大量的XML配置以及繁瑣的部署方式，使得它使用起來非常不便。雖然后來Sun公司又推出的EJB 3.X，在使用上簡化了很多，但依然無法成為Java開發的事實標準。由Rod Johnson這位業界大神開發的Spring Framework，極大的簡化了JavaEE的開發，它提供的IOC和AOP為開發者提供了便利，并且迅速地成為Java后端開發的實際標準。
? ??邏輯控制層，又叫MVC層，它是用于分離前臺展現和后端服務的部分。由于Java的標準實現Servlet侵入了大量如HttpRequest、HttpResponse、HttpSession等Servlet API。導致基于Sevlet開發的程序并不利于單元測試，而且其配置、跳轉、表單封裝等操作也需要做大量的重復工作，因此，產生了很多MVC框架用于改善開發工作。常見的MVC框架有Strtus 1.X，基于WebWork封裝的Struts 2.X和Spring MVC。初期Struts系列由于使用簡單而備受青睞，后來隨著Spring對MVC投入的加大，其更加清晰的設計理念以及強大的與Spring framework的融合能力，使得它漸漸成為業界主流。
在這種All in One的集中式架構下，每個開發者都是全棧工程師。
由Spring + Struts（Spring MVC）+ Hibernate組成的SSH框架套件或
由Spring + Struts（Spring MVC）+ IBatis（MyBatis）組成的SSI框架套件成為技術選型的主流。
2.分布式架構、SOA和服務化
? ??然而，對于互聯網應用規模的迅速增長，集中式架構并無法做到無限制的提升系統的吞吐量。它只能通過增加服務器的配置有限度的提升系統的處理能力，這種擴展方式被稱之為垂直擴展。與之相對的擴展方式叫做水平擴展，它能夠僅通過服務器數量的增減即可相應的提升和降低系統的吞吐量。這種分布式系統架構，在理論上為吞吐量的上升提供了無限擴展的可能。因此，用于搭建互聯網應用的服務器也漸漸地放棄了昂貴的小型機，轉而采用大量的廉價PC服務器。
? ??分布式系統的引入，雖然解決了整個應用的吞吐量上限問題，但它也并非銀彈。分布式在帶來便利的同時，也帶來了額外的復雜度。分布式場景下比較著名的難題就是CAP定理。CAP定理認為，在分布式系統中，系統的一致性、可用性和分區容忍性，三者不可能同時兼顧。在分布式系統中，由于網絡通信的不穩定，分區容忍性是必須要存在的，因此在設計應用的時候，就需要在一致性和可用性之間權衡選擇。在一致性和可用性之間，互聯網應用比企業級應用更加偏向可用性。因此，采用最終一致性代替傳統事務的ACID強一致性。
隨著分布式系統架構的普及，越來越多的互聯網公司在重新審視一個并不是嶄新，但卻一直難于落地的概念，那就是SOA。
? ??SOA即面向服務架構，它是一個特別大的話題，可以簡單的認為SOA約等于模塊化開發?+?分布式計算。SOA需要從宏觀和微觀兩個不同的角度討論。宏觀SOA面向高層次的部門級別、公司級別甚至行業級別，涉及商業、管理、技術等方面的綜合和全局的考慮。SOA最主要是面向宏觀層面的架構，其帶來收益也最能在宏觀的高層次上體現出來，因此，很多業界專家都認為SOA概念過于抽象、不接地氣。微觀SOA則面向團隊和個人，涉及具體的服務在業務、架構和開發上的考慮，架構體系上包括服務治理、服務編排等等。在微觀層面的SOA則更容易討論和實施。
? ??由于分布式系統是如此復雜，因此也產生了大量的分布式中間件和分布式數據庫，用于簡化分布式系統的開發。服務化的架構設計理念也被越來越多的公司所認同。2011年前后，阿里開源的Dubbo，是對后世影響深遠的一款分布式服務框架，也徹底的掀起了為早已拉開帷幕的分布式和SOA時代的最強音。服務發現、負載均衡、失效轉移、動態擴容、數據分片、調用鏈路監控等分布式系統的核心功能也一個個趨于成熟。
3.自動化運維
? ??隨著分布式系統的愈加成熟，越來越大的規模的應用和越來越復雜的系統構成也隨之而來，服務器的數量迅速地從幾十上百臺發展成為了成千上萬臺。企業內部服務器數量的大幅增長，使得出現故障的服務器頻次也大幅增加，手工運維時代的瓶頸也隨之到來。運維工程師越來越難以遠程登錄到每一臺服務器，去搭建環境、部署應用、清理磁盤、查看服務器狀態以及排查系統錯誤。
急需與開發技術體系配套的，是自動化運維體系。自動化運維工具主要包括兩大類：監控自動化工具以及流程自動化工具。
? ??監控自動化工具可以對服務器的CPU、內存、磁盤IO、網絡IO等重要指標進行主動式的探測監控，一旦指標超過或接近閥值則自動通過郵件、短信等方式通知相關責任人。Nagios、Zabbix等系統監控工具可以有效的解決這一問題。
流程自動化工具主要針對服務器的維護和應用上線部署等日常操作的自動化和標準化。Puppet、Chef、Ansible和SaltStack等自動化運維管理工具的出現，快速的將運維工作推向自動化，讓一個運維工程師可以很容易的維護上千臺服務器。
4.解放交付的DevOps
? ??分布式架構解決了互聯網應用吞吐量的瓶頸；越來越成熟的分布式中間件也屏蔽了分布式系統的復雜度，提升了開發工程師的工作效率；自動化運維工具也提升了運維工程師的工作效率。但是，由于目標不同，在固有的開發和運維劃分為不同部門的組織結構中，部門之間的配合并不總是很順暢。開發部門的驅動力通常是頻繁地交付新特性，而運維部門則更關注服務的可靠性。兩者目標的不匹配，就在開發與運維部門之間造成了鴻溝，從而降低了業務交付的價值的速度。
? ??直到DevOps方法論的出現，開發與運維之間的鴻溝才得以漸漸跨越。它是一系列可以幫助開發工程師和運維工程師在實現各自目標的前提下，向最終用戶交付最大化價值和最高質量成果的基本原則和實踐。DevOps在軟件開發和交付流程中強調在產品管理、軟件開發以及運維之間的溝通與協作。
DevOps是一種公司文化的變遷，它代表了開發、運維和測試等環節之間的協作，因此DevOps可以由多種工具組成一個完整的DevOps工具鏈，見下圖：
從分布式到云原生架構
? ??隨著虛擬化技術的成熟和分布式架構的普及，用來部署、管理和運行應用的云平臺被越來越多的提及。IaaS、PaaS和SaaS是云計算的3種基本服務類型，它們是關注硬件基礎設施的基礎設施即服務、關注軟件和中間件平臺的平臺即服務以及關注業務應用的軟件即服務。容器的出現，使原有的基于OpenStack的云主機應用，徹底轉變為更加靈活和輕量的容器+編排調度的云平臺應用。
1.新紀元的分水嶺?-?容器技術
? ??過去幾年云平臺在不斷地發展，但應用程序在云平臺運行，仍然需要為不同的開發語言安裝相應的運行時環境。雖然自動化運維工具可以降低環境搭建的復雜度，但仍然不能從根本上解決環境的問題。
? ??Docker的出現成為了軟件開發行業新的分水嶺；容器技術的成熟，也標志技術新紀元的開啟。Docker讓開發工程師可以將他們的應用和依賴封裝到一個可移植的容器中。就像當年智能手機的出現改變了整個手機行業的游戲規則一樣，Docker也大有席卷整個軟件行業，并且進而改變行業游戲規則的趨勢。通過集裝箱式的封裝，開發和運維都以標準化的方式發布的應用，異構語言不再是桎梏團隊的枷鎖。
2.新紀元的編排&調度系統
? ??而Kubernetes、Mesos和Docker swarm則為云原生應用提供的強有力的編排和調度能力，它們是云平臺上的分布式操作系統。
??? Kubernetes是目前世界上關注度最高的開源項目，它是一個出色的容器編排系統。Kubernetes出身于互聯網行業的巨頭Google公司，它借鑒了由上百位工程師花費十多年時間打造Borg系統的理念，通過極其簡易的安裝，以及靈活的網絡層對接方式，提供一站式的服務。
? ??Mesos則更善于構建一個可靠的平臺，用以運行多任務關鍵工作負載，包括Docker容器、遺留應用程序(例如Java)和分布式數據服務(例如Spark、Kafka、Cassandra、Elastic)。Mesos采用兩級調度的架構，開發人員可以很方便的結合公司業務場景自定制MesosFramework。
? ??通過Docker、Kunernetes以及Mesos的出色表現，為運維工程師的工作模式帶來了顛覆性的改變。他們再也無需像照顧寵物那樣精心的照顧每一臺服務器，而是只需要像照顧牲畜那樣，將出問題的服務器汰換掉即可。業務開發工程師不必再過分關注非功能需求，只需專注自己的業務領域即可。而中間件開發工程師，則需要開發出健壯的云原生中間件，用來連接業務應用與云平臺。
3.微服務
? ??單體應用雖然簡單且深入人心，但是隨著越來越多的應用被部署在云端，它的劣勢就體現的愈加明顯。因為應用變更的范圍和周期被捆綁在一起，即使只變更應用的一部分，也需要重新構建并部署整個單體應用，而且無法對需要更多資源的部分模塊單獨擴展，而是必須將整個應用整體擴展。這樣粗粒度的劃分，不利于系統的管理和資源的利用。因此，人們越來越傾向于將應用合理的拆分。
? ??在過去幾年中，微服務已經迅速的成為了技術圈最熱門的術語之一，微服務是一種架構風格，它將一個復雜的單體應用分解成為多個獨立部署的微型服務，每個服務運行在自己的進程中，服務間通信采用輕量級通信機制，如：RESTFul API。服務可以使用不同的開發語言和數據存儲技術。通過微服務的拆分，系統可以更加自由的所需資源分配到所需的應用中，而不是直接擴展整個應用。
? ??采用微服務架構風格的團隊將圍繞業務組織團隊而非圍繞技術組織團隊，這一點和DevOps有異曲同工之妙。單體式架構將大型應用拆分時，通常需要根據技術層面劃分為UI團隊、后端開發團隊好數據庫團隊。這種團隊的劃分方式，使得簡單的更改也會導致跨團隊協作。
? ? 在容器技術、編排系統等開源社區的推動下，以及微服務等開發理念的帶動下，應用上云已經是不可逆轉的趨勢。
? ? 隨著云化技術的不斷進展，云原生的概念有應運而生。在現有業務代碼不改變的情況下，分布式系統無縫入云，那么需要改變的就是中間件。因此分布式中間件向云原生中間件的變遷，即是本書的重點。
以上內容節選自《云原生分布式架構》一書
【內容簡介：互聯網架構不斷演化，經歷了從集中式架構到分布式架構，再到云原生架構的過程。云原生因能解決傳統應用升級緩慢、架構臃腫、不能快速迭代等問題而成為未來云端應用的目標。本書首先介紹了架構演化及云原生的概念，讓讀者對基礎概念有一個準確的了解。接著闡述容器調度、服務化、分布式等體系的原理，講解分布式中間件設計方法。最后輔以實戰，以中心化和平臺化角度切入，深度揭秘兩大開源項目Elastic-Job和Sharding-JDBC的實現】
原文：https://mp.weixin.qq.com/s/jlZ5kVZdKkKdnU3UyFys4w
.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com
總結
以上是生活随笔為你收集整理的架构演化：云原生时代开启之系列一演化篇的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 下一个计划 : .NET/.NET Co
- 下一篇： 基于OIDC（OpenID Connec