這是我看過關(guān)于微服務(wù)架構(gòu)最好的一篇文章,沒有之一

原文轉(zhuǎn)自一線互聯(lián)網(wǎng)資深架構(gòu)師里伯,微服務(wù)布道師小馬哥的原創(chuàng)文章

微服務(wù)是什么蝇恶?

微服務(wù)是一種細粒度(Fine-Grain)的SOA

或許在座的高朋了解過其概念。個人認為乘客,與其說微服務(wù)是一種技術(shù)狐血,不如將其定義為一種架構(gòu),而架構(gòu)則是“技”的實現(xiàn)與“術(shù)”的策略相輔相成易核⌒僦“術(shù)”的策略需要分析使用場景,進行合理地劃分業(yè)務(wù)邊界,實現(xiàn)“業(yè)以類聚”缀匕,然而“技”的實現(xiàn)則通過特定的技術(shù)在實現(xiàn)業(yè)務(wù)邏輯之時纳决,更多的考慮實現(xiàn)過程中的效率性、測試的便利性乡小、維護的可持續(xù)性阔加,達到“技以群分”的目的。

由此而論满钟,我個人偏好將其定義為:“微服務(wù)是一種細粒度的SOA”胜榔。

這樣定義的好處在于,沒必要去重復地“抹黑”“單體應用”(Monolithic零远,也有人翻譯成“巨石應用”)苗分,緣于SOA技術(shù)的衍化過程中早已提及。那么牵辣,細粒度更多的體現(xiàn)在“取其精華摔癣,去其糟粕”。

SOA又是什么?

**SOA = Service-Oriented Architecture**

SOA 中文定義是面向服務(wù)架構(gòu)纬向,它并非是今日的重點择浊,請原諒我不能花大篇幅來加以闡述。我用“點到為止”的方式描述SOA具備哪些特征逾条,以及相關(guān)的技術(shù)琢岩。

SOA有什么?

特征
  • 面向服務(wù)( Service-Oriented )

  • 松耦合(Loose-Coupling)

  • 模塊化(Modular)

  • 分布式計算(Distributed Computing)

  • 平臺無關(guān)性(Independent Platform)

  • 集中管理(Center Government)

技術(shù)

  • Web Services

    Web Services 技術(shù)演進的目的在于解決分布式計算中,統(tǒng)一異構(gòu)系統(tǒng)的服務(wù)調(diào)用的通訊協(xié)議师脂。前期的Web Services有XML-PRC担孔、WSDL、SOAP等技術(shù)吃警,不但解決了Windows平臺COM+以及Java 平臺RMI無法跨平臺的問題糕篇,而且使用了可讀性強的本文協(xié)議替代了復雜的二進制協(xié)議,如CORBA技術(shù)∽眯模現(xiàn)代的WebServices 技術(shù)主要代表有REST等拌消。

  • Message Queue

    Message Queue 技術(shù)設(shè)計的目的主要有兩個方面,從架構(gòu)上來說安券,消息隊列服務(wù)幫助系統(tǒng)之間依賴關(guān)系解耦墩崩;從技術(shù)上來看,消息隊列為系統(tǒng)提供異步處理的能力侯勉,解決了并發(fā)同步調(diào)用導致資源消耗過集中和過快等問題鹦筹,將上下游系統(tǒng)的數(shù)據(jù)結(jié)構(gòu)提供了統(tǒng)一的傳輸介質(zhì)。

  • ESB

    ESB 則是 SOA 集大成實現(xiàn)址貌。

SOA不是什么?

SOA ≠ Monolithic

SOA 不但不是Monolithic盛龄,而且是要解決Monolithic,Monolithic 個人偏好翻譯成“單體應用”,也被翻譯成“巨石應用”余舶。

Monolithic是什么?

[![這是我](http://upload-images.jianshu.io/upload_images/9005929-f856b463b08051ed?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)](http://mmbiz.qpic.cn/mmbiz_png/rVKYDsmJuM0ia58YDDa9DT2KwDsM06Crx7WBicY9RmJaV7oW4dBtviaj4XiaRamnLCmlUUibMZ52zRms9lRaM5ricy8w/640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1) 

故宮

朋友可能覺得奇怪,故宮與“單體應用”有什么關(guān)系锹淌?故宮是帝王居住和辦公的場所匿值,她象征著“最高權(quán)利”和“中央集權(quán)”。華夏民族赂摆,自秦朝的“三公九卿制”挟憔,還是隋朝的“三省六部制”,以及明清的“內(nèi)閣制度”烟号,無一例外地致力于鞏固“中央集權(quán)”绊谭。

近兩千年來,雖然王朝不斷更迭汪拥,這個制度一直被沿用达传,并且沒有出現(xiàn)大的詬病∑戎可是宪赶,1793年,英國勛爵馬戛爾尼出使中國脯燃,代表英皇為乾隆皇帝祝壽搂妻,也負有促成中英通商的使命。雖然當時的中國籠罩在“乾隆盛世”的光環(huán)下辕棚,不過在馬戛爾尼看來中國無論從科技還是社會制度上欲主,均處于相對落后的階段∈藕浚《左傳》有言:“民之多幸扁瓢,國之不幸”,當時的大多數(shù)國民視英國為“蠻夷”懈糯,不與商貿(mào)往來涤妒。五十年后,中英鴉片戰(zhàn)爭爆發(fā)赚哗,1840年她紫,中華帝國第一個不平等條約《南京條約》被迫簽訂,它不但打擊中華名族屿储,而且“打醒”了大和民族贿讹。明治維新后的日本,屢屢挑戰(zhàn)中國的東亞地位够掠,直到中日甲午戰(zhàn)爭失利民褂。1895年《馬關(guān)條約》簽訂,割臺灣,賠巨款赊堪。但仍有康有為等不愿放棄面殖,聯(lián)名千人“公車上書”,認為“中央集權(quán)”并不是問題所在哭廉〖沽牛“中央集權(quán)”職責臃腫,行政不力遵绰,中央政策想要對地方面面俱到是不可能的辽幌,無法做到“因地制宜”。

我想說的是椿访,單體應用不正像一個“中央集權(quán)”的政府嗎乌企?而微服務(wù)應用則更像“多權(quán)分立”的“自治”政府,各個“自治”政府之間在“聯(lián)邦”的架構(gòu)下“分工”和“協(xié)作”成玫。 

Why加酵?

“學而不思則罔”

為什么要微服務(wù)?

  • 效率的需要

    應用進行微服務(wù)化后梁剔,規(guī)模和體積變得更加輕量級虽画,在編譯、打包荣病、分發(fā)码撰、部署等環(huán)節(jié)節(jié)約了時間,開發(fā)上效率提升个盆。

  • 質(zhì)量的需要

    微服務(wù)應用面向持續(xù)集成友好脖岛,自動化編譯、單元和集成測試用例執(zhí)行和回歸颊亮,提高應用整體質(zhì)量柴梆。

  • 穩(wěn)定的需要

    當應用大而全時,往往牽一發(fā)而動全身终惑,其中一個服務(wù)出現(xiàn)問題绍在,整體受到牽動效應。整體穩(wěn)定性得不到保證雹有,因此偿渡,經(jīng)過微服務(wù)化后,應用由原來的服務(wù)內(nèi)部組裝到服務(wù)自由組合霸奕,一旦關(guān)聯(lián)服務(wù)存在問題溜宽,整體應用可以選擇性地降級或熔斷等措施,待問題服務(wù)恢復质帅,一切照常執(zhí)行适揉。

  • 運維的需要

    微服務(wù)應用具備自動化編譯留攒、打包、分發(fā)嫉嘀、部署和運維的能力炼邀。傳統(tǒng)的應用不但需要開發(fā)、還需要測試和運維人員吃沪,微服務(wù)應用實現(xiàn)后汤善,將理想化的全棧(Full-Stack)工程師變?yōu)榭赡堋?/p>

  • 成長的需要

    微服務(wù)能夠更好,更快地適配新技術(shù)票彪,比如目前流行的Apache Kafka。而工程人員需要接觸新的技術(shù)不狮,為未來可能的技術(shù)選型做好準備降铸。我的建議在一些不那么重要的微服務(wù)應用中,可以嘗試一些新的技術(shù)摇零,在其提供的功能與實際需要之間推掸,找到一些自己的理解,也是自我成長的需要驻仅。

為什么不必微服務(wù)谅畅?

論語有言:“子絕四:‘毋意、毋必噪服、毋固毡泻、毋我’≌秤牛”仇味,簡單地說,不要臆斷雹顺,不要固執(zhí)丹墨,不要自我感覺良好,也有什么是必定的嬉愧。那么贩挣,在微服務(wù)實踐過程中,哪些因素可以不必微服務(wù)呢没酣?請注意用詞王财,這里說的是“不必”,不是“不要”四康。 
  • 場景單一

    當應用的場景單一時搪搏,沒有必要非得微服務(wù),因為它本身就是微服務(wù)闪金,例如一些靜態(tài)的通告頁面疯溺。

  • 邏輯簡單

    當應用邏輯簡單時论颅,同樣也違背了微服務(wù)的初衷,因為微服務(wù)是為了解決復雜業(yè)務(wù)邏輯而衍生囱嫩,因此這種情況下也不必實施微服務(wù)恃疯。

  • 業(yè)務(wù)漸逝

    首先,我解釋一下“漸逝”墨闲,也就是逐漸消逝的意思今妄。當應用所關(guān)注的業(yè)務(wù)趨于消逝狀態(tài)時,盡管有實施的空間鸳碧,但無實施的必要盾鳞。因為這樣的應用隨時可能不復存在,好比沒有必要去對BB機或者短信業(yè)務(wù)大張旗鼓的重構(gòu)一般瞻离。

  • “老成持重”

    老成持重的原意是形容人做事情老練和沉穩(wěn)腾仅。這里我引用了這個成語,是為了方便記憶套利,需要將其拆開推励,單獨解釋。

    “老”是指年老的應用肉迫,多久算得上年老呢验辞?個人經(jīng)驗,應用服役年齡超過三年以上喊衫。

    “成”則表示應用的規(guī)模已成形跌造,業(yè)務(wù)上幾乎不再變化,比如通知應用格侯。

    “持”說明應用的場景還將持續(xù)較長時間鼻听。

    “重”表示應用所處的位置舉足輕重,不能隨時重構(gòu)联四,比如交易應用撑碴。

    當應用符合其中一條以上的特征時,該應用不必實行微服務(wù)朝墩。

  • 技術(shù)盲從

    這一點是我最為關(guān)注醉拓,也是最擔心朋友觸犯的。我們同為工程人員收苏,對技術(shù)的追求毋容置疑亿卤,可是千萬不能因為技術(shù)而技術(shù),新的技術(shù)推出或是解決現(xiàn)有問題鹿霸,或是提供便利性排吴,可是也有夸大其詞的成分。理性地評估和謹慎地實施懦鼠,更是我們更要關(guān)注的地方钻哩。技術(shù)困難挑戰(zhàn)聰明才智屹堰,理智對待則考驗情緒控制。

進階閱讀

網(wǎng)絡(luò)

http://microservices.io/

http://martinfowler.com/articles/microservices.html

書籍

《Microservice Architecture》, Irakli Nadareishvili

文稿

《2016.11.19 微服務(wù)實踐之路(廈門) 演講稿》 , 小馬哥 (本微信公眾號內(nèi))

以上推薦的網(wǎng)絡(luò)資源以及書籍可能大家已閱街氢,不過我主要是推薦我上月去廈門的演講稿扯键,之所以把它放在最后,目的確實想突出珊肃,“后其身而身先”(老子)嘛荣刑。: D

How

前面提到的部分是“What”和“Why”,接下來伦乔,進入“How”的部分厉亏,顧名思義,就是怎么做烈和,如何做的意思叶堆。

“多見闕殆,慎行其余”

以上兩句處于孔子的學生子張請教孔子關(guān)于如何干好工斥杜,孔子的回答是:“多聞闕疑,慎言其余沥匈,則寡尤蔗喂。多見闕殆,慎行其余高帖,則寡悔缰儿。言寡尤,行寡悔散址,祿在其中矣”乖阵。儒家經(jīng)典總在告誡我們,言行需謹慎预麸,如臨深淵瞪浸、如履薄冰,戰(zhàn)戰(zhàn)兢兢吏祸。個人認為將此等思想放諸四海而皆準对蒲,在微服務(wù)的實踐過程中,同樣需要謹慎因應贡翘。

怎么實現(xiàn)微服務(wù)

怎么樣實現(xiàn)微服務(wù)蹈矮,我想從以下三個方面來說明:
  • 心態(tài)

  • 技術(shù)

  • 思想

心態(tài)

  • “子路有聞,未之能行鸣驱,唯恐有聞”

    句中的開頭二字“子路”泛鸟,是一個人名∮欢孔子門徒三千北滥,七十二賢刚操,最著名的是“孔門十哲”,其中就包括子路碑韵。子路赡茸,也就是仲由,字子路祝闻。整句話的意思是說占卧,子路聽到新的知識或者道理,沒有付諸于實踐联喘,又擔心新的知識或道理的出現(xiàn)华蜒。這句話能很好地反應當今這個浮躁的互聯(lián)網(wǎng)時代,看似科技突飛猛進豁遭,新的技術(shù)層出不窮叭喜,而實踐不力,導致首鼠兩端的心態(tài)蓖谢。凡是他人掌握了新的技術(shù)捂蕴,自己卻沒有,就覺得不如人闪幽,反之亦然啥辨。我想告訴大家的是,微服務(wù)并不是新的技術(shù)盯腌,而是新的思路溉知,只不過咨詢發(fā)達,加上基礎(chǔ)的沉淀腕够,讓老的技術(shù)或理論在新的時代能夠“飛入尋常百姓家”级乍。

  • “不患無位,患所以立”

    當微服務(wù)被廣泛地被業(yè)界認可和接受時帚湘,或許你總會擔心在何處實踐玫荣,因此,在心態(tài)上客们,需要做到不要擔心它花落誰家崇决,更要放平心態(tài),思考它為什么存在的理由底挫。

  • “攻乎異端恒傻,斯害也已”

    當你或你的團隊在推廣微服務(wù)過程中,你得首先做好被挑戰(zhàn)甚至是攻擊的準備建邓,據(jù)不完全統(tǒng)計盈厘,世界上有5%的人,是因為反對而反對的人官边。但是反對負面情緒可能會印象其他50%的人沸手。由此前提之后外遇,還需具備攻擊“異端邪說”的能力,這樣就能達到“斯害也已”(這種危害也可以被消滅)契吉。

  • “過則勿憚改”

    最后一種心態(tài)則是不要怕犯錯跳仿,錯了不要忌憚改正。作為工程人員捐晶,實施的過程中不出錯是不可能的菲语,除非不去做。不要畏懼犯錯惑灵,犯錯也是更好地縮小內(nèi)心期望和現(xiàn)實情況的鴻溝山上,不犯錯就沒有成長的空間,因此英支,不怕錯栖袋,也不忌改正澡罚。

    前面的部分用了不少詩詞,接下來就不會那么“詩”了星立,來點“干”的捞稿,也是今天的技術(shù)重頭戲慎玖。馬上進入技術(shù)的部分钞楼。

**技術(shù) **

技術(shù)上蜈亩,在阿里微服務(wù)的實踐過程中也不能免俗,基本上也是以下三個套路:
  • Docker

  • DDD

  • Middleware(Java)

Docker

在阿里巴巴集團技術(shù)體系中修赞,自行研發(fā)與Docker兼容的AliDocker,并且提供了一些其他能力和輔助工具桑阶。本人相對這塊不是特別熟悉柏副,與我的同事一同討論和交流,這里只能做一些簡單地介紹蚣录。

如何一起學習割择,有沒有免費資料?

對Java技術(shù)萎河,架構(gòu)技術(shù)感興趣的同學荔泳,歡迎加QQ群619881427,一起學習虐杯,相互討論玛歌。

群內(nèi)已經(jīng)有小伙伴將知識體系整理好(源碼,筆記擎椰,PPT支子,學習視頻),歡迎加群免費領(lǐng)取达舒。

分享給喜歡Java值朋,喜歡編程叹侄,有夢想成為架構(gòu)師的程序員們,希望能夠幫助到你們昨登。

不是Java程序員也沒關(guān)系趾代,幫忙轉(zhuǎn)發(fā)給更多朋友!謝謝丰辣。

  • 測試環(huán)境:AliDocker + ECS(阿里云)

  • 生成環(huán)境:AliDocker + 物理機

DDD

DDD是Domain Driven Design(領(lǐng)域驅(qū)動設(shè)計)的簡寫撒强,該技術(shù)源于Eric Evans 在其名著《Domain Driven Design》。從年代來看糯俗,已是相當老的設(shè)計方法論了尿褪。它作為微服務(wù)重要的理論依據(jù),如今又如“鳳凰涅槃”一般得湘,重新進入軟件領(lǐng)域的視野杖玲。DDD的三大實施策略在具體微服務(wù)實踐過程中,取二舍一淘正。當然摆马,整個DDD的理論并不限于此,個人理解鸿吆,DDD好像是一個傳說囤采,大家都聽說過,但是誰也沒有見到過惩淳。而是實現(xiàn)這種理想就如同烏托邦式的“共產(chǎn)主義”蕉毯,目前仍未到時候。
  • 有界上下文(Bounded Context)

    有界上下文的思想思犁,個人認為是在《設(shè)計模式》中的“單職責原則”進一步發(fā)展而言代虾。其實也體現(xiàn)了東西方文化的差異,東方是以古代中國為代表的“中央集權(quán)”思想激蹲,和古希臘城邦的“三權(quán)分立”的民治思想棉磨。微服務(wù)則屬于“權(quán)力分立”思想的范疇。在微服務(wù)實踐過程中学辱,確定應用邊界是必要的乘瓤,也是困難的。必要性反應在系統(tǒng)職責劃分策泣,要簡約衙傀、清晰,不耦合萨咕。困難性則體現(xiàn)在重構(gòu)過程不是一蹴而就差油,而是循序漸進,同時,應用還伴隨著業(yè)務(wù)發(fā)展而同步開發(fā)蓄喇,其間的困難是可預知的发侵。雖然過程是痛苦的,但是也不得不去做妆偏。

  • 持續(xù)集成(Continuous integration)

    持續(xù)集成是繼承了TDD(Test Driven Development刃鳄,測試驅(qū)動開發(fā))的思想,對應形成規(guī)模的公司而言钱骂,基本上都部署了持續(xù)集成的環(huán)境叔锐,在阿里則是Aone 系統(tǒng)來統(tǒng)籌。一些流行的開源軟件见秽,如GitLab愉烙、Jenkins(Hudson)等。

  • 上下文映射(Context Map)

    以上兩個策略均在實踐中被采納解取,那么上下文映射(Context Map)則被舍棄步责,舍棄的原因并不在于其不合理,而是難以駕馭禀苦。例如蔓肯,用戶服務(wù)提供用戶的模型,其中包括了姓名振乏、生日蔗包、電話等』塾剩可是下游系統(tǒng)调限,需要僅僅需要用戶的姓名信息,而實際情況误澳,用戶服務(wù)無法提供這么細粒度的服務(wù)旧噪,那么不得不在中間做一層上下文映射,將兩者不再直接關(guān)聯(lián)脓匿。這種情況貌似還看不出端倪,可是為服務(wù)化后宦赠,服務(wù)數(shù)量眾多陪毡,其映射環(huán)節(jié)基本上不可控制,下游系統(tǒng)配合改動也是代價頗高勾扭,因此毡琉,在實踐過程中,還是保持原有的調(diào)用關(guān)系妙色。盡量做到改造過程中桅滋,減低錯誤率。

Middleware

中間件是微服務(wù)實施過程中不可或缺的一個環(huán)節(jié),實現(xiàn)中間件的編程語言可以任意丐谋,不過目前市場上最為流行還屬Java芍碧。經(jīng)剛才粗略的統(tǒng)計,在座的朋友們從事Java居多号俐,本人恰好也相對熟悉這個領(lǐng)域泌豆。接下來,我們一同來探討吏饿,Java 中間件在微服務(wù)實踐過程中的措施踪危。由于時間的關(guān)系,無法做到一一列舉猪落,因此贞远,以下每個小節(jié)均有實例說明。
  • Spring

  • Spring Boot

  • Spring Cloud

  • Spring Cloud Stream

  • Spring Boot DevOps

Spring

  • Annotation驅(qū)動

    在微服務(wù)實踐的過程中笨忌,中間件部門向各條業(yè)務(wù)線的開發(fā)推廣蓝仲,用Annotation驅(qū)動的方式替代過去XML配置的方式:

Annotation驅(qū)動方式

在Spring 3.1 以及更好的版本中,提供了大量的Annotation作為XML配置的替代一下方式(現(xiàn)場統(tǒng)計蜜唾,基本上沒有人知道這種方式):

XML配置方式

工程人員相對XML的方式更為熟悉杂曲,以上XML配置了是Spring WebMVC的一些組件Bean。實際上袁余,除了@EnableWebMvc以外擎勘,還提供了很多@EnableXXX的替代方式,例如@EnableAsync颖榜、@EnableAspectJAutoProxy等棚饵。在實施過程中,很多開發(fā)人員錯誤的認為這些是Spring Boot的帶來的便利掩完,其實不然噪漾。

Spring Boot

在Spring Boot 推廣實施過程中,除了以上Annotation重構(gòu)方式以外且蓬,我想在前端渲染引擎選型評估方面談?wù)勛约旱男牡煤腕w會欣硼,建議大家時刻保持懷疑的態(tài)度,一家之言恶阴,僅供參考诈胜。
  • 渲染引擎

Thymeleaf(Spring 推薦)

    • 優(yōu)點:HTML結(jié)構(gòu)化、UI友好冯事,表達式功能強大

      • HTML結(jié)構(gòu)化焦匈、UI友好

    Thymeleaf 設(shè)計初衷就是針對UI友好,讓開發(fā)人員在編輯模板頁面時昵仅,遵循標準HTML結(jié)構(gòu)缓熟。

      • 表達式功能強大

    不但兼容標準 OGNL 表達式,而且也支持Spring 表達。Spring 表達式為Spring 3 之后推出的重要功能提供動態(tài)的執(zhí)行程序的能力够滑。

    • 缺點:編碼略微繁瑣垦写、性能一般、擴展復雜
      • 編碼略微繁瑣

    沒有比較不存在優(yōu)劣版述,Thymeleaf 在編輯過程中相對繁瑣梯澜,相比較于Velocity和JSP而言。

      • 性能一般

    最明顯的缺點是渴析,性能著實一般晚伙,因此,不建議用在訪問過頻繁的頁面俭茧,比如寶貝詳情頁面咆疗。

      • 擴展復雜

    Thymeleaf 元素標簽相對比較復雜。

    以下為 Thymeleaf 模板頁面的內(nèi)容母债,其中“th”為Thymeleaf 標簽(tag)的命名空間(namespace):

Thymeleaf 模板頁面

Velocity(廣泛應用)

  • 優(yōu)點:性能良好午磁、易于擴展、事件處理毡们、配置靈活

    • 性能良好

    相比較于 Thymeleaf 而言迅皇,Velocity的性能良好。

    • 易于擴展

    在擴展性方面衙熔,Velocity提供宏(Marco)擴展登颓,實現(xiàn)代碼復用。

    • 事件處理

    開發(fā)人員可能對于事件處理上相對陌生红氯,我簡單地介紹以下框咙,Velocity 提"org.apache.velocity.app.event.EventHandler"接口,其中典型代表為:"org.apache.velocity.app.event.ReferenceInsertionEventHandler”接口痢甘,主要用于攔截引用插入前的事件喇嘱。

    • 配置靈活

    也是Velocity顯著特點,提供了大量靈活的配置項塞栅,方便開發(fā)人員設(shè)置者铜,例如配置模板位置、字符編碼等放椰。

  • 缺點:HTML結(jié)構(gòu)化不友好作烟、發(fā)展停滯

    • HTML結(jié)構(gòu)化不友好

    由于Velocity模板的語法特點并非HTML結(jié)構(gòu)化友好,指令(Directive)以及宏(Marco)均直接在頁面非標簽區(qū)域植入庄敛,比如 #set 這種寫法。

    • 發(fā)展停滯

    Velocity 1.7 版本自2010年以來科汗,不再更新藻烤,因此,Spring 4.3 版本(或者Spring Boot 1.4)開始,將Velocity支持標記為Deprecated怖亭。

常規(guī)Velocity模板

Velocity宏(Marco)

Velocity 指令(Directive)

** JSP(Java EE標準)**

  • 優(yōu)點:編碼靈活涎显、兼容性好、性能優(yōu)秀兴猩、多種頁面結(jié)構(gòu)化

    • 編碼靈活

    較以上兩種模板引擎期吓,JSP編碼方式更為靈活,其中包括:

      • Scriptlets

    早期類PHP腳本語法倾芝,即在JSP頁面中直接添加 Java 代碼讨勤,這種編程模式稱為 Scriptlets ,其對應的J2EE(當時還稱作J2EE晨另,即現(xiàn)在的Java EE)設(shè)計模型為Model 1潭千。

  • EL(Express Language)

    由于Scriptlets編程模式在頁面上植入太多的 Java 代碼,代碼既難以復用借尿,維護成本又相當巨大刨晴。JSP 2.0 規(guī)范引入了EL(Express Language)1.0 規(guī)范,隨后該能力被用在J2EE設(shè)計模式中路翻,逐步發(fā)展成 Model 2 以及 MVC 狈癞,JSP頁面不再負責數(shù)據(jù)組裝等邏輯,而是僅承載頁面渲染的作用(當然還是具備 Scriptlets 能力茂契,只是不推薦使用這種方式)蝶桶。

  • 兼容性好

    JSP屬于Java EE規(guī)范,因此Java EE均提供了實現(xiàn)账嚎,比如 Tomcat莫瞬、Jetty、WebLogic 等等郭蕉。因此疼邀,JSP 具備天然性兼容,不需要額外引入其他資源召锈。

  • 性能優(yōu)秀

    JSP屬于解釋編譯型模板語言旁振,無論是 Scriptlets 還是 EL 均可以翻譯成 Java 源文件,然后將 Java 源文件編譯成 Java Class 文件涨岁,再經(jīng)過容器加載并且執(zhí)行相關(guān)方法調(diào)用(可參考org.apache.jasper.servlet.JspServlet)拐袜。

  • 多種頁面結(jié)構(gòu)化

    這個特點是很多國內(nèi) Java 工程人員不太關(guān)注的特性,通常將JSP頁面結(jié)構(gòu)定格在HTML梢薪,實際上蹬铺,它的頁面結(jié)構(gòu)格式可以設(shè)置成更為嚴格的XHTML,甚至是XML秉撇。順便提一句甜攀,Thymeleaf 也具備該能力秋泄,而 Velocity 不具備。因此规阀,在我看來恒序,JSP 并不是太落伍,而是太超前谁撼。

  • 缺點:限制表達式(EL)歧胁、擴展繁瑣、規(guī)約較多厉碟、Servlet強依賴

    • 限制表達式(EL)

    EL 的實現(xiàn)是OGNL 表達式的子集喊巍,僅實現(xiàn)了簡單地數(shù)據(jù)讀取和邏輯運行。類似于 Bean 方法調(diào)用這樣的高級語法墨榄,需要配合 JSF 這樣的Web技術(shù)來配合( JSF 叫座不叫好的 Web 框架 )玄糟。

    • 擴展繁瑣

    JSP 擴展主要是JSP 標簽擴展,JSP 標簽擴展被很多人視為反模式袄秩,我倒不怎么認為阵翎,但是對其配置上倒是頗為復雜,舉個例子之剧,每個 Tag 的屬性需要綁定一個對應的實現(xiàn)類屬性郭卫,并且類型復雜,功能各異背稼,比如 IterationTag 和 BodyTag 的作用存在一定的區(qū)別贰军。

    • 規(guī)約較多

    JSP 除了tag lib的規(guī)約以外,還有jsp-property-group 等蟹肘,我用一段web.xml中的配置為例:

    <jsp-config>

    <taglib>
    
        <taglib-uri>http://tae-sdk.taobao.com/taglibs/sdk</taglib-uri>
    
        <taglib-location>/META-INF/config/taglibs/sdk-web-1.0.tld</taglib-location>
    
    </taglib>
    
    <jsp-property-group>
    
        <url-pattern>*.jsp</url-pattern>
    
        <page-encoding>GBK</page-encoding>
    
        <include-coda>/WEB-INF/jsp/coda/footer.jspf</include-coda>
    
        <trim-directive-whitespaces>true</trim-directive-whitespaces>
    
    </jsp-property-group>
    

    </jsp-config>

  • Servlet強依賴

    JSP 對于 Servlet API 是強依賴的词疼,主要執(zhí)行邏輯與Servlet 相同( init 方法、service 方法以及 destroy 方法 )帘腹,在現(xiàn)代化的Java Web 編程模式中贰盗,基本上屏蔽了Servlet API接口,比如 Spring WebMVC 中的@RequestParam 用于獲取請求參數(shù)阳欲,去取代Servlet API中的 javax.servlet.http.HttpServletRequest#getParameter(String) 方法舵盈,因為該方法僅返回 String 類型,如要轉(zhuǎn)化成 Integer 類型球化,不得不調(diào)用 Integer#valueOf(String) 方法進行轉(zhuǎn)化秽晚。再則,目前流行的HTTP 2 Web服務(wù)器 - Undertow 并不兼容 Servlet API 方案筒愚,因此 Spring Boot 官方文檔說明有一段特別說明:

Spring Boot 官方文檔說明

Spring Boot 部分點到為止赴蝇,會后可以進一步交流,接下來巢掺,進入Spring Cloud的部分句伶。

Spring Cloud

Spring Cloud 官方提供了基本功能描述芍耘,其中包括:分布式/版本化配置(Distributed/versioned configuration)、注冊與發(fā)現(xiàn)(Registry and Discovery)熄阻、路由(Routing)、服務(wù)調(diào)用(Service-to-service calls)倔约、負載均衡(Load balancing)秃殉、短路( Circuit Break )以及分布式消息(Distributed messaging)。技術(shù)點不少浸剩,這里我選取了分布式配置為例钾军。詳細描述,我已在《2016.11.19 微服務(wù)實踐之路(廈門) 演講稿》(本微信公眾號內(nèi))中提到绢要,請大家會后參考吏恭。 
  • 分布式配置

    Spring Framework 3.1 開始,提供了一個新的接口:org.springframework.core.env.Environment重罪,該接口的標準實現(xiàn)中組合了 org.springframework.core.env.PropertySources 對象(組合了多個org.springframework.core.env.PropertySource 對象)樱哼,利用這個對象可以方便地 resolve Property。同時剿配,PropertySources 可以追加新的 org.springframework.core.env.PropertySource 對象搅幅。因此,Spring Cloud 提供了一個定位器 org.springframework.cloud.bootstrap.config.PropertySourceLocator 能夠便利地追加org.springframework.core.env.PropertySource 對象到org.springframework.core.env.PropertySources 對象中呼胚。

    結(jié)合Alibaba 內(nèi)部分布式配置管理中間件 Diamond(類似于ZooKeeper)茄唐,部分實現(xiàn)邏輯如下:

部分實現(xiàn)邏輯

具體使用則是通過@Value的方式獲取配置內(nèi)容中的Property,將其關(guān)聯(lián)到對象字段中蝇更,如下圖:

字段與配置項映射代碼

在ArchimedesProperties上方沪编,有一個@RefreshScope的注解,這個注解的用途是通知 Spring Cloud年扩,如果配置項發(fā)生變更后蚁廓,變更后的屬性值將會同步到對象的字段值上。

下一張圖所示常遂,配置內(nèi)容監(jiān)聽器的實現(xiàn)纳令,符合現(xiàn)代Annotation 驅(qū)動的方式,將配置項的內(nèi)容轉(zhuǎn)化成需要的類型:

監(jiān)聽配置內(nèi)容類型裝換

Spring Cloud 部分完結(jié)克胳,下一個環(huán)節(jié)進入 Spring Cloud Stream平绩。

Spring Cloud Stream

在Martin Fowler的名著《Enterprise Integration Patterns》(企業(yè)整合模式 )中提到過(Channel)的概念,Spring Cloud Stream 付諸于實踐漠另,提供抽象實現(xiàn)捏雌。這種抽象實現(xiàn)的好處在于對應用透明,應用不再強制綁定在某種具體技術(shù)上笆搓,對它而言性湿,Spring Cloud Stream 為其建立管道(Channel)纬傲,其中有兩個概念被涉及:Source(發(fā)送端)和Sink(接收端)。

類似于 Kafka 消息中間件肤频,Alibaba 也自主研發(fā)了一套Message Queue叹括,名叫 MetaQ ,早一陣子提交到開源社區(qū) Apache 上宵荒,與 Kalfa 為同級的項目汁雷,很了不起。無論是 Kafka 還是 MetaQ 都有自帶的API报咳,為了增加應用依賴透明性侠讯,針對 MetaQ 做了Spring Cloud Stream 的適配,如下圖所示:

Source(發(fā)送端)發(fā)送消息實例代碼

Source(發(fā)送端)發(fā)送消息實例代碼:

Sink(接收器)消費消息實例代碼

以上代碼相當簡單暑刃,與JMS中的消息訂閱模式類似厢漩。

前面三小節(jié)均為實現(xiàn)部分,最后一個技術(shù)小節(jié)岩臣,繼續(xù)討論一下針對 Spring Boot 的 DevOps溜嗜。

Spring Boot DevOps

  • 整體架構(gòu)

Archimedes整體架構(gòu)圖

每個微服務(wù)應用均有一個應用名,通過接入 Eureka Client 架谎,向注冊中心 Eureka Server 注冊粱胜。Eureka Server保存所有注冊應用的信息,這些信息被 Archimedes 通過Eureka Client 提供 REST 接口獲取狐树,將獲取的應用列表并發(fā)地獲取他們的Endpoint 和 Metrics信息焙压。同時 Archimedes 也提供了REST API 接口,暴露應用元信息給 Archimedes Dashboard 提供頁面展示抑钟。將需要的Metrics信息存放時序數(shù)據(jù)庫涯曲,比如OpenTSDB。再通過OpenTSDB的HTTP API進行查詢在塔,最后將查詢結(jié)果顯示在監(jiān)控頁面中幻件。
  • 線程管理

    Archimedes Dashboard 提供了圖形化的線程管理,如下單實例線程總數(shù)時序圖所示:

單實例線程總數(shù)時序圖

下圖所示蛔溃,其功能類似于JStack绰沥,將具體線程運行的狀態(tài)以及堆棧詳細列出:

活動線程堆棧信息

  • 內(nèi)存管理

    JVM 的內(nèi)存管理相對比較復雜,不但包括內(nèi)存部分贺待,內(nèi)存池徽曲、和相關(guān)垃圾回收的算法。其中JVM 內(nèi)存有包括:Jjava 內(nèi)存使用麸塞、堆使用秃臣、以及非堆使用。

    在 Archimedes Dashboard 中,將幾者結(jié)合起來奥此,集中展示弧哎。

整體內(nèi)存使用情況以及垃圾回收

垃圾回收前后對比

內(nèi)存池使用詳情

  • 日志管理

    個人認為日志管理是獨創(chuàng),雖然Spring Admin 也提供了日志切換的能力稚虎,不過它不具備多種日志實現(xiàn)一同切換的能力撤嫩,其中適配了四種流行的日志框架:Java Logging、Log4j蠢终、Log4j2 以及 Logback非洲。

log4j 日志調(diào)控

Logback 日志調(diào)控

Archimedes 中會自動識別應用所使用的日志框架,雖然不推薦一個應用中使用多套日志框架蜕径,可是現(xiàn)實情況不得不一并思考,比如有些二方j(luò)ar包中存在的獨立的日志處理败京。

思想

聊完了技術(shù)兜喻,下面來談?wù)勊枷敕矫娴膶崿F(xiàn),我總結(jié)為三大點:
  • 少談”敏捷”

    國外很多流派在“吹噓”赡麦,敏捷已死朴皆。不好我覺得有些夸張的成分,但是也無需過度的實施泛粹,借鑒一點即可遂铡。

  • 推崇”簡潔”

    簡潔很重要,牢記“Simple is beautiful”晶姊。微服務(wù)系統(tǒng)設(shè)計越簡潔越好扒接,這里簡潔不是簡單。

  • 學習“狄仁杰”

    這點可能很多朋友覺得非常突兀们衙,和狄仁杰有什么關(guān)系钾怔。這里這么描述主要是狄閣老總問李元芳:“元芳,你怎么看蒙挑?”宗侦。這種不恥下問的精神,知道我們來學習忆蚀。狄仁杰并非事事明察矾利,也需要李元芳這樣的武夫分析和提點,能夠達到破案的目的,有為何不可呢匆赃?

朋友們巨缘,你們怎么看?
如何一起學習剑肯,有沒有免費資料?

對Java技術(shù)观堂,架構(gòu)技術(shù)感興趣的同學让网,歡迎加QQ群619881427呀忧,一起學習,相互討論溃睹。

群內(nèi)已經(jīng)有小伙伴將知識體系整理好(源碼而账,筆記,PPT因篇,學習視頻)泞辐,歡迎加群免費領(lǐng)取。

分享給喜歡Java竞滓,喜歡編程咐吼,有夢想成為架構(gòu)師的程序員們,希望能夠幫助到你們商佑。

不是Java程序員也沒關(guān)系锯茄,幫忙轉(zhuǎn)發(fā)給更多朋友!謝謝茶没。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末肌幽,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子抓半,更是在濱河造成了極大的恐慌喂急,老刑警劉巖,帶你破解...
    沈念sama閱讀 210,978評論 6 490
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件笛求,死亡現(xiàn)場離奇詭異廊移,居然都是意外死亡,警方通過查閱死者的電腦和手機探入,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 89,954評論 2 384
  • 文/潘曉璐 我一進店門画机,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人新症,你說我怎么就攤上這事步氏。” “怎么了徒爹?”我有些...
    開封第一講書人閱讀 156,623評論 0 345
  • 文/不壞的土叔 我叫張陵荚醒,是天一觀的道長。 經(jīng)常有香客問我隆嗅,道長界阁,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 56,324評論 1 282
  • 正文 為了忘掉前任胖喳,我火速辦了婚禮泡躯,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己较剃,他們只是感情好咕别,可當我...
    茶點故事閱讀 65,390評論 5 384
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著写穴,像睡著了一般惰拱。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上啊送,一...
    開封第一講書人閱讀 49,741評論 1 289
  • 那天偿短,我揣著相機與錄音,去河邊找鬼馋没。 笑死昔逗,一個胖子當著我的面吹牛,可吹牛的內(nèi)容都是我干的篷朵。 我是一名探鬼主播勾怒,決...
    沈念sama閱讀 38,892評論 3 405
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼款票!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起泽论,我...
    開封第一講書人閱讀 37,655評論 0 266
  • 序言:老撾萬榮一對情侶失蹤艾少,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后翼悴,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體缚够,經(jīng)...
    沈念sama閱讀 44,104評論 1 303
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 36,451評論 2 325
  • 正文 我和宋清朗相戀三年鹦赎,在試婚紗的時候發(fā)現(xiàn)自己被綠了谍椅。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 38,569評論 1 340
  • 序言:一個原本活蹦亂跳的男人離奇死亡古话,死狀恐怖雏吭,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情陪踩,我是刑警寧澤杖们,帶...
    沈念sama閱讀 34,254評論 4 328
  • 正文 年R本政府宣布,位于F島的核電站肩狂,受9級特大地震影響摘完,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜傻谁,卻給世界環(huán)境...
    茶點故事閱讀 39,834評論 3 312
  • 文/蒙蒙 一孝治、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦谈飒、人聲如沸岂座。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,725評論 0 21
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽掺逼。三九已至,卻和暖如春瓤介,著一層夾襖步出監(jiān)牢的瞬間吕喘,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 31,950評論 1 264
  • 我被黑心中介騙來泰國打工刑桑, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留氯质,地道東北人。 一個月前我還...
    沈念sama閱讀 46,260評論 2 360
  • 正文 我出身青樓祠斧,卻偏偏與公主長得像闻察,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子琢锋,可洞房花燭夜當晚...
    茶點故事閱讀 43,446評論 2 348

推薦閱讀更多精彩內(nèi)容