微服務是什麼？
微服務是一種細粒度（Fine-Grain）的SOA
或許在座的高朋瞭解過其概念。個人認為，與其說微服務是一種技術，不如將其定義為一種架構，而架構則是"技"的實現與"術"的策略相輔相成。
"術"的策略需要分析使用場景，進行合理地劃分業務邊界，實現"業以類聚"，然而"技"的實現則通過特定的技術在實現業務邏輯之時，更多的考慮實現過程中的效率性、測試的便利性、維護的可持續性，達到"技以群分"的目的。
由此而論，我個人偏好將其定義為："微服務是一種細粒度的SOA"。
這樣定義的好處在於，沒必要去重複地"抹黑""單體應用"（Monolithic，也有人翻譯成"巨石應用"），緣於SOA技術的衍化過程中早已提及。那麼，細粒度更多的體現在"取其精華，去其糟粕"。
SOA又是什麼?
**SOA = Service-Oriented Architecture**
SOA 中文定義是面向服務架構，它並非是今日的重點，請原諒我不能花大篇幅來加以闡述。我用"點到為止"的方式描述SOA具備哪些特徵，以及相關的技術。
SOA有什麼?
特徵
· 面向服務（ Service-Oriented ）
· 松耦合（Loose-Coupling）
· 模塊化（Modular）
· 分佈式計算（Distributed Computing）
· 平臺無關性（Independent Platform）
· 集中管理（Center Government）
技術
· Web Services
Web Services 技術演進的目的在於解決分佈式計算中，統一異構系統的服務調用的通訊協議。前期的Web Services有XML-PRC、WSDL、SOAP等技術，不但解決了Windows平臺COM+以及Java 平臺RMI無法跨平臺的問題，而且使用了可讀性強的本文協議替代了複雜的二進制協議，如CORBA技術。現代的WebServices 技術主要代表有REST等。
· Message Queue
Message Queue 技術設計的目的主要有兩個方面:
從架構上來說，消息隊列服務幫助系統之間依賴關係解耦；
從技術上來看，消息隊列為系統提供異步處理的能力，解決了併發同步調用導致資源消耗過集中和過快等問題，將上下游系統的數據結構提供了統一的傳輸介質。
· ESB
ESB 則是 SOA 集大成實現。
SOA不是什麼?
SOA ≠ Monolithic
SOA 不但不是Monolithic，而且是要解決Monolithic，Monolithic 個人偏好翻譯成"單體應用"，也被翻譯成"巨石應用"。
Monolithic是什麼?
朋友可能覺得奇怪，故宮與"單體應用"有什麼關係？故宮是帝王居住和辦公的場所，她象徵著"最高權利"和"中央集權"。華夏民族，自秦朝的"三公九卿制"，還是隋朝的"三省六部制"，以及明清的"內閣制度"，無一例外地致力於鞏固"中央集權"。
近兩千年來，雖然王朝不斷更迭，這個制度一直被沿用，並且沒有出現大的詬病。可是，1793年，英國勳爵馬戛爾尼出使中國，代表英皇為乾隆皇帝祝壽，也負有促成中英通商的使命。雖然當時的中國籠罩在"乾隆盛世"的光環下，不過在馬戛爾尼看來中國無論從科技還是社會制度上，均處於相對落後的階段。
《左傳》有言："民之多幸，國之不幸"，當時的大多數國民視英國為"蠻夷"，不與商貿往來。五十年後，中英鴉片戰爭爆發，1840年，中華帝國第一個不平等條約《南京條約》被迫簽訂，它不但打擊中華名族，而且"打醒"了大和民族。明治維新後的日本，屢屢挑戰中國的東亞地位，直到中日甲午戰爭失利。1895年《馬關條約》簽訂，割臺灣，賠鉅款。但仍有康有為等不願放棄，聯名千人"公車上書"，認為"中央集權"並不是問題所在。"中央集權"職責臃腫，行政不力，中央政策想要對地方面面俱到是不可能的，無法做到"因地制宜"。
我想說的是，單體應用不正像一個"中央集權"的政府嗎？而微服務應用則更像"多權分立"的"自治"政府，各個"自治"政府之間在"聯邦"的架構下"分工"和"協作"。
差異對比：
Why？
"學而不思則罔"
為什麼要微服務？
· 效率的需要
應用進行微服務化後，規模和體積變得更加輕量級，在編譯、打包、分發、部署等環節節約了時間，開發上效率提升。
· 質量的需要
微服務應用面向持續集成友好，自動化編譯、單元和集成測試用例執行和迴歸，提高應用整體質量。
· 穩定的需要
當應用大而全時，往往牽一髮而動全身，其中一個服務出現問題，整體受到牽動效應。整體穩定性得不到保證，因此，經過微服務化後，應用由原來的服務內部組裝到服務自由組合，一旦關聯服務存在問題，整體應用可以選擇性地降級或熔斷等措施，待問題服務恢復，一切照常執行。
· 運維的需要
微服務應用具備自動化編譯、打包、分發、部署和運維的能力。傳統的應用不但需要開發、還需要測試和運維人員，微服務應用實現後，將理想化的全棧（Full-Stack）工程師變為可能。
· 成長的需要
微服務能夠更好，更快地適配新技術，比如目前流行的Apache Kafka。而工程人員需要接觸新的技術，為未來可能的技術選型做好準備。我的建議在一些不那麼重要的微服務應用中，可以嘗試一些新的技術，在其提供的功能與實際需要之間，找到一些自己的理解，也是自我成長的需要。
為什麼不必微服務？
論語有言："子絕四：'毋意、毋必、毋固、毋我'。"，簡單地說，不要臆斷，不要固執，不要自我感覺良好，也有什麼是必定的。
那麼，在微服務實踐過程中，哪些因素可以不必微服務呢？請注意用詞，這裡說的是"不必"，不是"不要"。
· 場景單一
當應用的場景單一時，沒有必要非得微服務，因為它本身就是微服務，例如一些靜態的通告頁面。
· 邏輯簡單
當應用邏輯簡單時，同樣也違背了微服務的初衷，因為微服務是為了解決複雜業務邏輯而衍生，因此這種情況下也不必實施微服務。
· 業務漸逝
首先，我解釋一下"漸逝"，也就是逐漸消逝的意思。當應用所關注的業務趨於消逝狀態時，儘管有實施的空間，但無實施的必要。因為這樣的應用隨時可能不復存在，好比沒有必要去對BB機或者短信業務大張旗鼓的重構一般。
· "老成持重"
老成持重的原意是形容人做事情老練和沉穩。這裡我引用了這個成語，是為了方便記憶，需要將其拆開，單獨解釋。
"老"是指年老的應用，多久算得上年老呢？個人經驗，應用服役年齡超過三年以上。
"成"則表示應用的規模已成形，業務上幾乎不再變化，比如通知應用。
"持"說明應用的場景還將持續較長時間。
"重"表示應用所處的位置舉足輕重，不能隨時重構，比如交易應用。
當應用符合其中一條以上的特徵時，該應用不必實行微服務。
· 技術盲從
這一點是我最為關注，也是最擔心朋友觸犯的。我們同為工程人員，對技術的追求毋容置疑，可是千萬不能因為技術而技術，新的技術推出或是解決現有問題，或是提供便利性，可是也有誇大其詞的成分。理性地評估和謹慎地實施，更是我們更要關注的地方。技術困難挑戰聰明才智，理智對待則考驗情緒控制。
進階閱讀
How
前面提到的部分是"What"和"Why"，接下來，進入"How"的部分，顧名思義，就是怎麼做，如何做的意思。
"多見闕殆，慎行其餘"
以上兩句處於孔子的學生子張請教孔子關於如何幹好工，孔子的回答是："多聞闕疑，慎言其餘，則寡尤。多見闕殆，慎行其餘，則寡悔。言寡尤，行寡悔，祿在其中矣"。儒家經典總在告誡我們，言行需謹慎，如臨深淵、如履薄冰，戰戰兢兢。個人認為將此等思想放諸四海而皆準，在微服務的實踐過程中，同樣需要謹慎因應。
怎麼實現微服務
怎麼樣實現微服務，我想從以下三個方面來說明： 心態· 技術 · 思想
心態
· "子路有聞，未之能行，唯恐有聞"
句中的開頭二字"子路"，是一個人名。孔子門徒三千，七十二賢，最著名的是"孔門十哲"，其中就包括子路。子路，也就是仲由，字子路。整句話的意思是說，子路聽到新的知識或者道理，沒有付諸於實踐，又擔心新的知識或道理的出現。這句話能很好地反應當今這個浮躁的互聯網時代，看似科技突飛猛進，新的技術層出不窮，而實踐不力，導致首鼠兩端的心態。凡是他人掌握了新的技術，自己卻沒有，就覺得不如人，反之亦然。我想告訴大家的是，微服務並不是新的技術，而是新的思路，只不過資訊發達，加上基礎的沉澱，讓老的技術或理論在新的時代能夠"飛入尋常百姓家"。
· "不患無位，患所以立"
當微服務被廣泛地被業界認可和接受時，或許你總會擔心在何處實踐，因此，在心態上，需要做到不要擔心它花落誰家，更要放平心態，思考它為什麼存在的理由。
· "攻乎異端，斯害也已"
當你或你的團隊在推廣微服務過程中，你得首先做好被挑戰甚至是攻擊的準備，據不完全統計，世界上有5%的人，是因為反對而反對的人。但是反對負面情緒可能會印象其他50%的人。由此前提之後，還需具備攻擊"異端邪說"的能力，這樣就能達到"斯害也已"（這種危害也可以被消滅）。
· "過則勿憚改"
最後一種心態則是不要怕犯錯，錯了不要忌憚改正。作為工程人員，實施的過程中不出錯是不可能的，除非不去做。不要畏懼犯錯，犯錯也是更好地縮小內心期望和現實情況的鴻溝，不犯錯就沒有成長的空間，因此，不怕錯，也不忌改正。
前面的部分用了不少詩詞，接下來就不會那麼"詩"了，來點"幹"的，也是今天的技術重頭戲。馬上進入技術的部分。
技術
技術上，在阿里微服務的實踐過程中也不能免俗，基本上也是以下三個套路：
· Docker
· DDD
· Middleware（Java）
Docker
在阿里巴巴集團技術體系中，自行研發與Docker兼容的AliDocker，並且提供了一些其他能力和輔助工具。本人相對這塊不是特別熟悉，與我的同事一同討論和交流，這裡只能做一些簡單地介紹。
如何一起學習，有沒有免費資料？
對Java技術，架構技術感興趣的同學，歡迎加QQ群619881427，一起學習，相互討論。
群內已經有小夥伴將知識體系整理好（源碼，筆記，PPT，學習視頻），歡迎加群免費領取。
分享給喜歡Java，喜歡編程，有夢想成為架構師的程序員們，希望能夠幫助到你們。
不是Java程序員也沒關係，幫忙轉發給更多朋友！謝謝。
· 測試環境：AliDocker + ECS（阿里雲）
· 生成環境：AliDocker + 物理機
DDD
DDD是Domain Driven Design（領域驅動設計）的簡寫，該技術源於Eric Evans 在其名著《Domain Driven Design》。從年代來看，已是相當老的設計方法論了。它作為微服務重要的理論依據，如今又如"鳳凰涅槃"一般，重新進入軟件領域的視野。DDD的三大實施策略在具體微服務實踐過程中，取二舍一。當然，整個DDD的理論並不限於此，個人理解，DDD好像是一個傳說，大家都聽說過，但是誰也沒有見到過。而是實現這種理想就如同烏托邦式的"共產主義"，目前仍未到時候。
· 有界上下文（Bounded Context）
有界上下文的思想，個人認為是在《設計模式》中的"單職責原則"進一步發展而言。其實也體現了東西方文化的差異，東方是以古代中國為代表的"中央集權"思想，和古希臘城邦的"三權分立"的民治思想。微服務則屬於"權力分立"思想的範疇。在微服務實踐過程中，確定應用邊界是必要的，也是困難的。必要性反應在系統職責劃分，要簡約、清晰，不耦合。困難性則體現在重構過程不是一蹴而就，而是循序漸進，同時，應用還伴隨著業務發展而同步開發，其間的困難是可預知的。雖然過程是痛苦的，但是也不得不去做。
· 持續集成（Continuous integration）
持續集成是繼承了TDD（Test Driven Development，測試驅動開發）的思想，對應形成規模的公司而言，基本上都部署了持續集成的環境，在阿里則是Aone 系統來統籌。一些流行的開源軟件，如GitLab、Jenkins（Hudson）等。
· 上下文映射（Context Map）
以上兩個策略均在實踐中被採納，那麼上下文映射（Context Map）則被捨棄，捨棄的原因並不在於其不合理，而是難以駕馭。例如，用戶服務提供用戶的模型，其中包括了姓名、生日、電話等。可是下游系統，需要僅僅需要用戶的姓名信息，而實際情況，用戶服務無法提供這麼細粒度的服務，那麼不得不在中間做一層上下文映射，將兩者不再直接關聯。這種情況貌似還看不出端倪，可是為服務化後，服務數量眾多，其映射環節基本上不可控制，下游系統配合改動也是代價頗高，因此，在實踐過程中，還是保持原有的調用關係。儘量做到改造過程中，減低錯誤率。
Middleware
中間件是微服務實施過程中不可或缺的一個環節，實現中間件的編程語言可以任意，不過目前市場上最為流行還屬Java。經剛才粗略的統計，在座的朋友們從事Java居多，本人恰好也相對熟悉這個領域。接下來，我們一同來探討，Java 中間件在微服務實踐過程中的措施。由於時間的關係，無法做到一一列舉，因此，以下每個小節均有實例說明。
· Spring
· Spring Boot
· Spring Cloud
· Spring Cloud Stream
· Spring Boot DevOps
Spring
· Annotation驅動
在微服務實踐的過程中，中間件部門向各條業務線的開發推廣，用Annotation驅動的方式替代過去XML配置的方式：
Annotation驅動方式
在Spring 3.1 以及更好的版本中，提供了大量的Annotation作為XML配置的替代一下方式（現場統計，基本上沒有人知道這種方式）：
XML配置方式
工程人員相對XML的方式更為熟悉，以上XML配置了是Spring WebMVC的一些組件Bean。實際上，除了@EnableWebMvc以外，還提供了很多@EnableXXX的替代方式，例如@EnableAsync、@EnableAspectJAutoProxy等。在實施過程中，很多開發人員錯誤的認為這些是Spring Boot的帶來的便利，其實不然。
Spring Boot
在Spring Boot 推廣實施過程中，除了以上Annotation重構方式以外，我想在前端渲染引擎選型評估方面談談自己的心得和體會，建議大家時刻保持懷疑的態度，一家之言，僅供參考。
· 渲染引擎
Thymeleaf（Spring 推薦）
· 優點：HTML結構化、UI友好，表達式功能強大
· HTML結構化、UI友好
Thymeleaf 設計初衷就是針對UI友好，讓開發人員在編輯模板頁面時，遵循標準HTML結構。
· 表達式功能強大
不但兼容標準 OGNL 表達式，而且也支持Spring 表達。Spring 表達式為Spring 3 之後推出的重要功能提供動態的執行程序的能力。
· 缺點：編碼略微繁瑣、性能一般、擴展複雜
· 編碼略微繁瑣
沒有比較不存在優劣，Thymeleaf 在編輯過程中相對繁瑣，相比較於Velocity和JSP而言。
· 性能一般
最明顯的缺點是，性能著實一般，因此，不建議用在訪問過頻繁的頁面，比如寶貝詳情頁面。
·
· 擴展複雜
Thymeleaf 元素標籤相對比較複雜。
以下為 Thymeleaf 模板頁面的內容，其中"th"為Thymeleaf 標籤（tag）的命名空間（namespace）：
Thymeleaf 模板頁面
Velocity（廣泛應用）
· 優點：性能良好、易於擴展、事件處理、配置靈活
·
· 性能良好
相比較於 Thymeleaf 而言，Velocity的性能良好。
·
· 易於擴展
在擴展性方面，Velocity提供宏（Marco）擴展，實現代碼複用。
·
· 事件處理
開發人員可能對於事件處理上相對陌生，我簡單地介紹以下，Velocity 提"org.apache.velocity.app.event.EventHandler"接口，其中典型代表為："org.apache.velocity.app.event.ReferenceInsertionEventHandler"接口，主要用於攔截引用插入前的事件。
·
· 配置靈活
也是Velocity顯著特點，提供了大量靈活的配置項，方便開發人員設置，例如配置模板位置、字符編碼等。
· 缺點：HTML結構化不友好、發展停滯
·
· HTML結構化不友好
由於Velocity模板的語法特點並非HTML結構化友好，指令（Directive）以及宏（Marco）均直接在頁面非標籤區域植入，比如 #set 這種寫法。
·
· 發展停滯
Velocity 1.7 版本自2010年以來，不再更新，因此，Spring 4.3 版本（或者Spring Boot 1.4）開始，將Velocity支持標記為Deprecated。
常規Velocity模板
Velocity宏（Marco）
Velocity 指令（Directive）
** JSP（Java EE標準）**
· 優點：編碼靈活、兼容性好、性能優秀、多種頁面結構化
·
· 編碼靈活
較以上兩種模板引擎，JSP編碼方式更為靈活，其中包括：
·
·
· Scriptlets
早期類PHP腳本語法，即在JSP頁面中直接添加 Java 代碼，這種編程模式稱為 Scriptlets ，其對應的J2EE（當時還稱作J2EE，即現在的Java EE）設計模型為Model 1。
· EL（Express Language）
由於Scriptlets編程模式在頁面上植入太多的 Java 代碼，代碼既難以複用，維護成本又相當巨大。JSP 2.0 規範引入了EL（Express Language）1.0 規範，隨後該能力被用在J2EE設計模式中，逐步發展成 Model 2 以及 MVC ，JSP頁面不再負責數據組裝等邏輯，而是僅承載頁面渲染的作用（當然還是具備 Scriptlets 能力，只是不推薦使用這種方式）。
· 兼容性好
JSP屬於Java EE規範，因此Java EE均提供了實現，比如 Tomcat、Jetty、WebLogic 等等。因此，JSP 具備天然性兼容，不需要額外引入其他資源。
· 性能優秀
JSP屬於解釋編譯型模板語言，無論是 Scriptlets 還是 EL 均可以翻譯成 Java 源文件，然後將 Java 源文件編譯成 Java Class 文件，再經過容器加載並且執行相關方法調用（可參考org.apache.jasper.servlet.JspServlet）。
· 多種頁面結構化
這個特點是很多國內 Java 工程人員不太關注的特性，通常將JSP頁面結構定格在HTML，實際上，它的頁面結構格式可以設置成更為嚴格的XHTML，甚至是XML。順便提一句，Thymeleaf 也具備該能力，而 Velocity 不具備。因此，在我看來，JSP 並不是太落伍，而是太超前。
· 缺點：限制表達式（EL）、擴展繁瑣、規約較多、Servlet強依賴
·
· 限制表達式（EL）
EL 的實現是OGNL 表達式的子集，僅實現了簡單地數據讀取和邏輯運行。類似於 Bean 方法調用這樣的高級語法，需要配合 JSF 這樣的Web技術來配合（ JSF 叫座不叫好的 Web 框架 ）。
·
· 擴展繁瑣
JSP 擴展主要是JSP 標籤擴展，JSP 標籤擴展被很多人視為反模式，我倒不怎麼認為，但是對其配置上倒是頗為複雜，舉個例子，每個 Tag 的屬性需要綁定一個對應的實現類屬性，並且類型複雜，功能各異，比如 IterationTag 和 BodyTag 的作用存在一定的區別。
·
· 規約較多
JSP 除了tag lib的規約以外，還有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>
<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>
· Servlet強依賴
JSP 對於 Servlet API 是強依賴的，主要執行邏輯與Servlet 相同（ init 方法、service 方法以及 destroy 方法 ），在現代化的Java Web 編程模式中，基本上屏蔽了Servlet API接口，比如 Spring WebMVC 中的@RequestParam 用於獲取請求參數，去取代Servlet API中的 javax.servlet.http.HttpServletRequest#getParameter(String) 方法，因為該方法僅返回 String 類型，如要轉化成 Integer 類型，不得不調用 Integer#valueOf(String) 方法進行轉化。再則，目前流行的HTTP 2 Web服務器 - Undertow 並不兼容 Servlet API 方案，因此 Spring Boot 官方文檔說明有一段特別說明：
Spring Boot 官方文檔說明
Spring Boot 部分點到為止，會後可以進一步交流，接下來，進入Spring Cloud的部分。
Spring Cloud
Spring Cloud 官方提供了基本功能描述，其中包括：分佈式/版本化配置（Distributed/versioned configuration）、註冊與發現（Registry and Discovery）、路由（Routing）、服務調用（Service-to-service calls）、負載均衡（Load balancing）、短路（ Circuit Break ）以及分佈式消息（Distributed messaging）。技術點不少，這裡我選取了分佈式配置為例。詳細描述，我已在《2016.11.19 微服務實踐之路（廈門） 演講稿》(本微信公眾號內）中提到，請大家會後參考。
· 分佈式配置
Spring Framework 3.1 開始，提供了一個新的接口：org.springframework.core.env.Environment，該接口的標準實現中組合了 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 對象中。
結合Alibaba 內部分佈式配置管理中間件 Diamond（類似於ZooKeeper），部分實現邏輯如下：
部分實現邏輯
具體使用則是通過@Value的方式獲取配置內容中的Property，將其關聯到對象字段中，如下圖：
字段與配置項映射代碼
在ArchimedesProperties上方，有一個@RefreshScope的註解，這個註解的用途是通知 Spring Cloud，如果配置項發生變更後，變更後的屬性值將會同步到對象的字段值上。
下一張圖所示，配置內容監聽器的實現，符合現代Annotation 驅動的方式，將配置項的內容轉化成需要的類型：
監聽配置內容類型裝換
Spring Cloud 部分完結，下一個環節進入 Spring Cloud Stream。
Spring Cloud Stream
在Martin Fowler的名著《Enterprise Integration Patterns》（企業整合模式 ）中提到過（Channel）的概念，Spring Cloud Stream 付諸於實踐，提供抽象實現。這種抽象實現的好處在於對應用透明，應用不再強制綁定在某種具體技術上，對它而言，Spring Cloud Stream 為其建立管道（Channel），其中有兩個概念被涉及：Source（發送端）和Sink（接收端）。
類似於 Kafka 消息中間件，Alibaba 也自主研發了一套Message Queue，名叫 MetaQ ，早一陣子提交到開源社區 Apache 上，與 Kalfa 為同級的項目，很了不起。無論是 Kafka 還是 MetaQ 都有自帶的API，為了增加應用依賴透明性，針對 MetaQ 做了Spring Cloud Stream 的適配，如下圖所示：
Source（發送端）發送消息實例代碼
Source（發送端）發送消息實例代碼：
Sink（接收器）消費消息實例代碼
以上代碼相當簡單，與JMS中的消息訂閱模式類似。
前面三小節均為實現部分，最後一個技術小節，繼續討論一下針對 Spring Boot 的 DevOps。
Spring Boot DevOps
· 整體架構
Archimedes整體架構圖
每個微服務應用均有一個應用名，通過接入 Eureka Client ，向註冊中心 Eureka Server 註冊。Eureka Server保存所有註冊應用的信息，這些信息被 Archimedes 通過Eureka Client 提供 REST 接口獲取，將獲取的應用列表併發地獲取他們的Endpoint 和 Metrics信息。同時 Archimedes 也提供了REST API 接口，暴露應用元信息給 Archimedes Dashboard 提供頁面展示。將需要的Metrics信息存放時序數據庫，比如OpenTSDB。再通過OpenTSDB的HTTP API進行查詢，最後將查詢結果顯示在監控頁面中。
· 線程管理
Archimedes Dashboard 提供了圖形化的線程管理，如下單實例線程總數時序圖所示：
單實例線程總數時序圖
下圖所示，其功能類似於JStack，將具體線程運行的狀態以及堆棧詳細列出：
活動線程堆棧信息
· 內存管理
JVM 的內存管理相對比較複雜，不但包括內存部分，內存池、和相關垃圾回收的算法。其中JVM 內存有包括：Jjava 內存使用、堆使用、以及非堆使用。
在 Archimedes Dashboard 中，將幾者結合起來，集中展示。
整體內存使用情況以及垃圾回收
垃圾回收前後對比
內存池使用詳情
· 日誌管理
個人認為日誌管理是獨創，雖然Spring Admin 也提供了日誌切換的能力，不過它不具備多種日誌實現一同切換的能力，其中適配了四種流行的日誌框架：Java Logging、Log4j、Log4j2 以及 Logback。
log4j 日誌調控
Logback 日誌調控
Archimedes 中會自動識別應用所使用的日誌框架，雖然不推薦一個應用中使用多套日誌框架，可是現實情況不得不一併思考，比如有些二方jar包中存在的獨立的日誌處理。
思想
聊完了技術，下面來談談思想方面的實現，我總結為三大點：
· 少談"敏捷"
國外很多流派在"吹噓"，敏捷已死。不好我覺得有些誇張的成分，但是也無需過度的實施，借鑑一點即可。
· 推崇"簡潔"
簡潔很重要，牢記"Simple is beautiful"。微服務系統設計越簡潔越好，這裡簡潔不是簡單。
· 學習"狄仁傑"
這點可能很多朋友覺得非常突兀，和狄仁傑有什麼關係。這裡這麼描述主要是狄閣老總問李元芳："元芳，你怎麼看？"。這種不恥下問的精神，知道我們來學習。狄仁傑並非事事明察，也需要李元芳這樣的武夫分析和提點，能夠達到破案的目的，有為何不可呢？
閱讀更多 程序員瓦力 的文章
