信息技術從出現(xiàn)伊始到漸成主流，其趨勢經(jīng)歷了軟件尺铣、開源和云三個階段：
軟件改變世界≌瑁縱觀人類社會漫長的發(fā)展歷程凛忿，農(nóng)耕時代竞川、工業(yè)時代與信息時代可謂是三個明顯分水嶺，每個時代人類涉及的領域范疇均噴井式增長荣回。作為信息時代最重要的載體，互聯(lián)網(wǎng)越來越成為當今社會關注的焦點，互聯(lián)網(wǎng)的基石之一册踩，軟件正在迅速地改變著這個世界暂吉。
開源改變軟件慕的。隨著軟件行業(yè)的積累與成熟肮街，相比于重復制造輪子嫉父，站在巨人的肩膀上則更加容易和快速地創(chuàng)造出優(yōu)秀的新產(chǎn)品眼刃。隨著開源文化的認可度越來越高擂红，使用優(yōu)秀的開源產(chǎn)品作為基礎構架，快速搭建系統(tǒng)以實現(xiàn)市場戰(zhàn)略是當今的最優(yōu)資源配比方案树碱。
云吞噬開源赴恨。對互聯(lián)網(wǎng)近乎100%可用性的需要伦连，僅通過開源產(chǎn)品搭建并運維一個高可用额港、高度彈性化的平臺并非易事移斩。因此向瓷，提供技術思路的同時，進一步提供整套云解決方案瓷耙，以保障不斷擴展的非功能需求搁痛，是當今新一代互聯(lián)網(wǎng)平臺的追求长搀。
在信息技術的大潮中，每一次通信的升級源请，都會對世界的合作模式產(chǎn)生改變彻况。隨著互聯(lián)網(wǎng)在本世紀初大規(guī)模的接入巢钓，互聯(lián)網(wǎng)由基于流量點擊盈利的單方面信息發(fā)布門戶的web 1.0業(yè)務模式疗垛，轉(zhuǎn)變?yōu)榱擞捎脩糁鲗Ф蓛?nèi)容的互聯(lián)網(wǎng)產(chǎn)品症汹，即web 2.0業(yè)務模式。因此贷腕，互聯(lián)網(wǎng)應用系統(tǒng)所需處理的訪問量和數(shù)據(jù)量均急速增長，后端技術架構也因此面臨著巨大的挑戰(zhàn)泽裳。這一階段的互聯(lián)網(wǎng)后端架構大多由All in One的單體式應用架構漸漸的轉(zhuǎn)向為更加靈活的分布式應用架構涮总；而企業(yè)級架構由于功能復雜裳扯，而且并未出現(xiàn)明顯的系統(tǒng)瓶頸，因而并未跟進允蜈。后端開發(fā)由單一技術棧漸漸區(qū)分開來冤吨，越來越明顯的劃分為企業(yè)級開發(fā)和互聯(lián)網(wǎng)開發(fā)。企業(yè)級開發(fā)和互聯(lián)網(wǎng)開發(fā)的差別不僅在于技術棧饶套，也在于工作模式漩蟆，對質(zhì)量的追求與對效率的提升成為了兩個陣營的分水嶺。
隨著智能手機出現(xiàn)以及4G信號的普及妓蛮，互聯(lián)網(wǎng)應用由PC端迅速轉(zhuǎn)向更加自由的移動端怠李，由于攜帶方便且便于定位，在出行仔引、網(wǎng)購、付款等方面徹底了改變的現(xiàn)代人的生活方式褐奥。在技術方面咖耘，為了應對更加巨大的規(guī)模，單純的分布式系統(tǒng)已經(jīng)難以駕馭撬码。技術圈也因此契機開啟了一個概念爆發(fā)的時代儿倒，SOA、DevOps呜笑、容器夫否、CI\CD、微服務叫胁、Service Mesh等概念層出不窮凰慈，而Docker、Kubernetes驼鹅、Mesos微谓、Spring Cloud、gRPC等一系列產(chǎn)品的出現(xiàn)输钩，標志著云時代真正的到來豺型。
云時代下的互聯(lián)網(wǎng)架構變遷
互聯(lián)網(wǎng)應用的業(yè)務特征決定它和企業(yè)級應用的諸多不同，主要有以下幾點：
1.海量用戶
互聯(lián)網(wǎng)應用幾乎無差別的服務于全世界所有的用戶买乃，與服務于局域網(wǎng)用戶的企業(yè)級應用相比姻氨，它們的用戶量基數(shù)差距很大，由海量用戶產(chǎn)生的數(shù)據(jù)量也會成幾何級增長剪验。
2.產(chǎn)品迭代迅速
隨著業(yè)務模式的快速拓展肴焊，互聯(lián)網(wǎng)應用功能推陳出新的速度越來越快前联。在當今如此快節(jié)奏的時代，時間成本非常關鍵抖韩。
3.7*24不間斷服務
互聯(lián)網(wǎng)應用作為一個面向全球的服務蛀恩，時區(qū)的差異，使得應用必須保證全天隨時可用茂浮，每次宕機都會產(chǎn)生很大的損失双谆。
4.流量突增
不同類型的互聯(lián)網(wǎng)公司有著各自不同的流量突增場景。比如席揽，電商類公司會在雙十一這樣的大促期間流量突增幾倍顽馋、幾十倍甚至上百倍；社交類公司會在熱點事件爆發(fā)的時候流量突增幌羞。
5.業(yè)務組合復雜
很多互聯(lián)網(wǎng)公司都是跨界巨頭寸谜，即使并非跨界，在單一領域属桦，編織一個大規(guī)模的成型業(yè)務也并不簡單熊痴。以電商行業(yè)舉例，在應用系統(tǒng)層面大致會劃分為賣場聂宾、交易果善、訂單、倉儲系谐、物流等主流程系統(tǒng)巾陕；搜索、推薦纪他、社區(qū)鄙煤、會員、客服茶袒、退換貨等面向用戶的前端系統(tǒng)梯刚；商品、價格薪寓、庫存乾巧、配貨、促銷预愤、供應鏈等面向后臺員工的后端系統(tǒng)沟于；以及廣告、商家植康、支付旷太、清算、財務、報表等面向合作伙伴的輔助系統(tǒng)供璧。而每個應用系統(tǒng)又會劃分為很多子系統(tǒng)存崖。一個粗略的電商系統(tǒng)業(yè)務架構圖：
由于互聯(lián)網(wǎng)行業(yè)業(yè)務特征的特殊性以及勢不可擋的擴張速度，相應的底層支撐的技術挑戰(zhàn)也越來越大睡毒，究其根本原因是其不斷擴張的規(guī)模来惧。由規(guī)模而衍生的問題包括海量數(shù)據(jù)、響應遲緩演顾、穩(wěn)定性差供搀、伸縮性差、系統(tǒng)繁多和開發(fā)困難等問題钠至。
因此針對這些問題葛虐，互聯(lián)網(wǎng)的技術架構也在逐漸的轉(zhuǎn)變，以
集中式 –>分布式-> 云平臺的方向演進棉钧。
從集中式到分布式架構
集中式架構又叫單體式架構屿脐，在web2.0模式并未大規(guī)模興起時，十分流行宪卿。進入新世紀以來的诵，基于web應用的B/S架構逐漸的取代了基于桌面應用的C/S架構。B/S架構的后端系統(tǒng)佑钾，大都采用集中式架構西疤，它當時以優(yōu)雅的分層設計，統(tǒng)一了服務器后端的開發(fā)領域次绘。
1.傳統(tǒng)的三層架構模型
在web 2.0剛開始流行的時候瘪阁，互聯(lián)網(wǎng)應用與企業(yè)級應用并沒有本質(zhì)的區(qū)別撒遣，集中式應用分為標準的3層架構模型：數(shù)據(jù)訪問層邮偎、服務層和邏輯控制層。每個層之間既可以共享領域模型對象义黎，也可以做更加細致的拆分禾进。
由于NoSQL在當時還并未興起，因此數(shù)據(jù)庫訪問層主要是關系型數(shù)據(jù)庫的訪問廉涕，出現(xiàn)了很多ORM框架泻云。MyBatis及其前身IBatis、JPA以及它的默認實現(xiàn)Hibernate都是ORM領域中開源框架的翹楚狐蜕。
服務層用于編寫應用的具體業(yè)務邏輯宠纯，它需要一個使用便捷且可以對數(shù)據(jù)訪問層和邏輯控制層能夠承前啟后的框架。Java官方所推薦的EJB 2.X過于笨重层释，大量的XML配置以及繁瑣的部署方式婆瓜，使得它使用起來非常不便。雖然后來Sun公司又推出的EJB 3.X，在使用上簡化了很多廉白，但依然無法成為Java開發(fā)的事實標準个初。由Rod Johnson這位業(yè)界大神開發(fā)的Spring Framework，極大的簡化了JavaEE的開發(fā)猴蹂，它提供的IOC和AOP為開發(fā)者提供了便利院溺，并且迅速地成為Java后端開發(fā)的實際標準。
邏輯控制層磅轻，又叫MVC層珍逸，它是用于分離前臺展現(xiàn)和后端服務的部分。由于Java的標準實現(xiàn)Servlet侵入了大量如HttpRequest瓢省、HttpResponse弄息、HttpSession等Servlet API。導致基于Sevlet開發(fā)的程序并不利于單元測試勤婚，而且其配置摹量、跳轉(zhuǎn)、表單封裝等操作也需要做大量的重復工作馒胆，因此缨称，產(chǎn)生了很多MVC框架用于改善開發(fā)工作。常見的MVC框架有Strtus 1.X祝迂，基于WebWork封裝的Struts 2.X和Spring MVC睦尽。初期Struts系列由于使用簡單而備受青睞，后來隨著Spring對MVC投入的加大型雳，其更加清晰的設計理念以及強大的與Spring framework的融合能力当凡，使得它漸漸成為業(yè)界主流。
在這種All in One的集中式架構下纠俭，每個開發(fā)者都是全棧工程師沿量。
由Spring + Struts（Spring MVC）+ Hibernate組成的SSH框架套件或
由Spring + Struts（Spring MVC）+ IBatis（MyBatis）組成的SSI框架套件成為技術選型的主流。
2.分布式架構冤荆、SOA和服務化
然而朴则，對于互聯(lián)網(wǎng)應用規(guī)模的迅速增長，集中式架構并無法做到無限制的提升系統(tǒng)的吞吐量钓简。它只能通過增加服務器的配置有限度的提升系統(tǒng)的處理能力乌妒，這種擴展方式被稱之為垂直擴展。與之相對的擴展方式叫做水平擴展外邓，它能夠僅通過服務器數(shù)量的增減即可相應的提升和降低系統(tǒng)的吞吐量撤蚊。這種分布式系統(tǒng)架構，在理論上為吞吐量的上升提供了無限擴展的可能损话。因此侦啸，用于搭建互聯(lián)網(wǎng)應用的服務器也漸漸地放棄了昂貴的小型機，轉(zhuǎn)而采用大量的廉價PC服務器。
分布式系統(tǒng)的引入匹中，雖然解決了整個應用的吞吐量上限問題夏漱，但它也并非銀彈。分布式在帶來便利的同時顶捷，也帶來了額外的復雜度挂绰。分布式場景下比較著名的難題就是CAP定理。CAP定理認為服赎，在分布式系統(tǒng)中葵蒂，系統(tǒng)的一致性、可用性和分區(qū)容忍性重虑，三者不可能同時兼顧践付。在分布式系統(tǒng)中，由于網(wǎng)絡通信的不穩(wěn)定缺厉，分區(qū)容忍性是必須要存在的永高，因此在設計應用的時候，就需要在一致性和可用性之間權衡選擇提针。在一致性和可用性之間命爬，互聯(lián)網(wǎng)應用比企業(yè)級應用更加偏向可用性。因此辐脖，采用最終一致性代替?zhèn)鹘y(tǒng)事務的ACID強一致性饲宛。
隨著分布式系統(tǒng)架構的普及，越來越多的互聯(lián)網(wǎng)公司在重新審視一個并不是嶄新嗜价，但卻一直難于落地的概念艇抠，那就是SOA。
SOA即面向服務架構久锥，它是一個特別大的話題家淤，可以簡單的認為SOA約等于模塊化開發(fā) + 分布式計算。SOA需要從宏觀和微觀兩個不同的角度討論奴拦。宏觀SOA面向高層次的部門級別媒鼓、公司級別甚至行業(yè)級別届吁，涉及商業(yè)错妖、管理、技術等方面的綜合和全局的考慮疚沐。SOA最主要是面向宏觀層面的架構暂氯，其帶來收益也最能在宏觀的高層次上體現(xiàn)出來，因此亮蛔，很多業(yè)界專家都認為SOA概念過于抽象痴施、不接地氣。微觀SOA則面向團隊和個人，涉及具體的服務在業(yè)務辣吃、架構和開發(fā)上的考慮动遭，架構體系上包括服務治理、服務編排等等神得。在微觀層面的SOA則更容易討論和實施厘惦。
由于分布式系統(tǒng)是如此復雜，因此也產(chǎn)生了大量的分布式中間件和分布式數(shù)據(jù)庫哩簿，用于簡化分布式系統(tǒng)的開發(fā)宵蕉。服務化的架構設計理念也被越來越多的公司所認同。2011年前后节榜，阿里開源的Dubbo羡玛，是對后世影響深遠的一款分布式服務框架，也徹底的掀起了為早已拉開帷幕的分布式和SOA時代的最強音宗苍。服務發(fā)現(xiàn)稼稿、負載均衡、失效轉(zhuǎn)移讳窟、動態(tài)擴容渺杉、數(shù)據(jù)分片、調(diào)用鏈路監(jiān)控等分布式系統(tǒng)的核心功能也一個個趨于成熟挪钓。
3.自動化運維
隨著分布式系統(tǒng)的愈加成熟是越，越來越大的規(guī)模的應用和越來越復雜的系統(tǒng)構成也隨之而來，服務器的數(shù)量迅速地從幾十上百臺發(fā)展成為了成千上萬臺碌上。企業(yè)內(nèi)部服務器數(shù)量的大幅增長倚评，使得出現(xiàn)故障的服務器頻次也大幅增加，手工運維時代的瓶頸也隨之到來馏予。運維工程師越來越難以遠程登錄到每一臺服務器天梧，去搭建環(huán)境、部署應用霞丧、清理磁盤呢岗、查看服務器狀態(tài)以及排查系統(tǒng)錯誤。
急需與開發(fā)技術體系配套的蛹尝，是自動化運維體系后豫。自動化運維工具主要包括兩大類：監(jiān)控自動化工具以及流程自動化工具。
監(jiān)控自動化工具可以對服務器的CPU突那、內(nèi)存挫酿、磁盤IO、網(wǎng)絡IO等重要指標進行主動式的探測監(jiān)控愕难，一旦指標超過或接近閥值則自動通過郵件早龟、短信等方式通知相關責任人惫霸。Nagios、Zabbix等系統(tǒng)監(jiān)控工具可以有效的解決這一問題葱弟。
流程自動化工具主要針對服務器的維護和應用上線部署等日常操作的自動化和標準化壹店。Puppet、Chef芝加、Ansible和SaltStack等自動化運維管理工具的出現(xiàn)茫打，快速的將運維工作推向自動化，讓一個運維工程師可以很容易的維護上千臺服務器妖混。
4.解放交付的DevOps
分布式架構解決了互聯(lián)網(wǎng)應用吞吐量的瓶頸老赤；越來越成熟的分布式中間件也屏蔽了分布式系統(tǒng)的復雜度，提升了開發(fā)工程師的工作效率制市；自動化運維工具也提升了運維工程師的工作效率抬旺。但是，由于目標不同祥楣，在固有的開發(fā)和運維劃分為不同部門的組織結構中开财，部門之間的配合并不總是很順暢。開發(fā)部門的驅(qū)動力通常是頻繁地交付新特性误褪，而運維部門則更關注服務的可靠性责鳍。兩者目標的不匹配，就在開發(fā)與運維部門之間造成了鴻溝兽间，從而降低了業(yè)務交付的價值的速度历葛。
直到DevOps方法論的出現(xiàn)，開發(fā)與運維之間的鴻溝才得以漸漸跨越嘀略。它是一系列可以幫助開發(fā)工程師和運維工程師在實現(xiàn)各自目標的前提下恤溶，向最終用戶交付最大化價值和最高質(zhì)量成果的基本原則和實踐。DevOps在軟件開發(fā)和交付流程中強調(diào)在產(chǎn)品管理帜羊、軟件開發(fā)以及運維之間的溝通與協(xié)作咒程。
DevOps是一種公司文化的變遷，它代表了開發(fā)讼育、運維和測試等環(huán)節(jié)之間的協(xié)作帐姻，因此DevOps可以由多種工具組成一個完整的DevOps工具鏈，見下圖：
從分布式到云原生架構
隨著虛擬化技術的成熟和分布式架構的普及奶段，用來部署饥瓷、管理和運行應用的云平臺被越來越多的提及。IaaS忧饭、PaaS和SaaS是云計算的3種基本服務類型扛伍，它們是關注硬件基礎設施的基礎設施即服務筷畦、關注軟件和中間件平臺的平臺即服務以及關注業(yè)務應用的軟件即服務词裤。容器的出現(xiàn)刺洒，使原有的基于OpenStack的云主機應用，徹底轉(zhuǎn)變?yōu)楦屿`活和輕量的容器+編排調(diào)度的云平臺應用吼砂。
1.新紀元的分水嶺 - 容器技術
過去幾年云平臺在不斷地發(fā)展逆航，但應用程序在云平臺運行，仍然需要為不同的開發(fā)語言安裝相應的運行時環(huán)境渔肩。雖然自動化運維工具可以降低環(huán)境搭建的復雜度因俐，但仍然不能從根本上解決環(huán)境的問題。
Docker的出現(xiàn)成為了軟件開發(fā)行業(yè)新的分水嶺周偎；容器技術的成熟，也標志技術新紀元的開啟。Docker讓開發(fā)工程師可以將他們的應用和依賴封裝到一個可移植的容器中铐炫。就像當年智能手機的出現(xiàn)改變了整個手機行業(yè)的游戲規(guī)則一樣唠粥，Docker也大有席卷整個軟件行業(yè)，并且進而改變行業(yè)游戲規(guī)則的趨勢蛉艾。通過集裝箱式的封裝钳踊，開發(fā)和運維都以標準化的方式發(fā)布的應用，異構語言不再是桎梏團隊的枷鎖勿侯。
2.新紀元的編排&調(diào)度系統(tǒng)
而Kubernetes拓瞪、Mesos和Docker swarm則為云原生應用提供的強有力的編排和調(diào)度能力，它們是云平臺上的分布式操作系統(tǒng)助琐。
Kubernetes是目前世界上關注度最高的開源項目祭埂，它是一個出色的容器編排系統(tǒng)。Kubernetes出身于互聯(lián)網(wǎng)行業(yè)的巨頭Google公司兵钮，它借鑒了由上百位工程師花費十多年時間打造Borg系統(tǒng)的理念沟堡，通過極其簡易的安裝，以及靈活的網(wǎng)絡層對接方式矢空，提供一站式的服務航罗。
Mesos則更善于構建一個可靠的平臺，用以運行多任務關鍵工作負載屁药，包括Docker容器粥血、遺留應用程序(例如Java)和分布式數(shù)據(jù)服務(例如Spark、Kafka酿箭、Cassandra复亏、Elastic)。Mesos采用兩級調(diào)度的架構缭嫡，開發(fā)人員可以很方便的結合公司業(yè)務場景自定制MesosFramework缔御。
通過Docker、Kunernetes以及Mesos的出色表現(xiàn)妇蛀，為運維工程師的工作模式帶來了顛覆性的改變耕突。他們再也無需像照顧寵物那樣精心的照顧每一臺服務器笤成，而是只需要像照顧牲畜那樣，將出問題的服務器汰換掉即可眷茁。業(yè)務開發(fā)工程師不必再過分關注非功能需求炕泳，只需專注自己的業(yè)務領域即可。而中間件開發(fā)工程師上祈，則需要開發(fā)出健壯的云原生中間件培遵，用來連接業(yè)務應用與云平臺。
3.微服務
單體應用雖然簡單且深入人心登刺，但是隨著越來越多的應用被部署在云端籽腕，它的劣勢就體現(xiàn)的愈加明顯。因為應用變更的范圍和周期被捆綁在一起纸俭，即使只變更應用的一部分节仿，也需要重新構建并部署整個單體應用，而且無法對需要更多資源的部分模塊單獨擴展掉蔬，而是必須將整個應用整體擴展廊宪。這樣粗粒度的劃分，不利于系統(tǒng)的管理和資源的利用女轿。因此箭启，人們越來越傾向于將應用合理的拆分。
在過去幾年中蛉迹，微服務已經(jīng)迅速的成為了技術圈最熱門的術語之一傅寡，微服務是一種架構風格，它將一個復雜的單體應用分解成為多個獨立部署的微型服務北救，每個服務運行在自己的進程中荐操，服務間通信采用輕量級通信機制，如：RESTFul API珍策。服務可以使用不同的開發(fā)語言和數(shù)據(jù)存儲技術托启。通過微服務的拆分，系統(tǒng)可以更加自由的所需資源分配到所需的應用中攘宙，而不是直接擴展整個應用屯耸。
采用微服務架構風格的團隊將圍繞業(yè)務組織團隊而非圍繞技術組織團隊，這一點和DevOps有異曲同工之妙蹭劈。單體式架構將大型應用拆分時疗绣，通常需要根據(jù)技術層面劃分為UI團隊、后端開發(fā)團隊好數(shù)據(jù)庫團隊铺韧。這種團隊的劃分方式多矮，使得簡單的更改也會導致跨團隊協(xié)作。
在容器技術哈打、編排系統(tǒng)等開源社區(qū)的推動下塔逃，以及微服務等開發(fā)理念的帶動下讯壶，應用上云已經(jīng)是不可逆轉(zhuǎn)的趨勢。
隨著云化技術的不斷進展患雏，云原生的概念有應運而生鹏溯。在現(xiàn)有業(yè)務代碼不改變的情況下罢维，分布式系統(tǒng)無縫入云淹仑，那么需要改變的就是中間件。因此分布式中間件向云原生中間件的變遷肺孵，即是本書的重點匀借。
以上內(nèi)容節(jié)選自《云原生分布式架構》一書
【內(nèi)容簡介：互聯(lián)網(wǎng)架構不斷演化，經(jīng)歷了從集中式架構到分布式架構平窘，再到云原生架構的過程吓肋。云原生因能解決傳統(tǒng)應用升級緩慢、架構臃腫瑰艘、不能快速迭代等問題而成為未來云端應用的目標是鬼。本書首先介紹了架構演化及云原生的概念，讓讀者對基礎概念有一個準確的了解紫新。接著闡述容器調(diào)度均蜜、服務化、分布式等體系的原理芒率，講解分布式中間件設計方法囤耳。最后輔以實戰(zhàn)，以中心化和平臺化角度切入偶芍，深度揭秘兩大開源項目Elastic-Job和Sharding-JDBC的實現(xiàn)】
《云原生分布式架構》預計2018年與大家見面
書名尚未完全確定充择，歡迎微信公眾號留言提供更好的想法
原文鏈接：https://mp.weixin.qq.com/s/jlZ5kVZdKkKdnU3UyFys4w
