在構(gòu)建整個(gè)系統(tǒng)之前，先構(gòu)建3個(gè)互相交互的服務(wù)原型，找出實(shí)現(xiàn)非功能需求的解決方案，比如安全問(wèn)題、服務(wù)發(fā)現(xiàn)、健康監(jiān)控、回壓、失效備援，等等。

在被問(wèn)及是否可推薦一些用于微服務(wù)開(kāi)發(fā)的特定開(kāi)發(fā)語(yǔ)言或技術(shù)時(shí)，研討會(huì)參與嘉賓之一的Adam Bien說(shuō)：

Java已經(jīng)誕生20多年了，它是一門(mén)成熟的開(kāi)發(fā)語(yǔ)言，具有強(qiáng)大的工具和監(jiān)控能力。Java在一開(kāi)始就融入了微服務(wù)概念，比如Jini/JXTA框架，它們與No-SQL數(shù)據(jù)庫(kù)（比如JavaSpaces）混在一起。可以說(shuō)，Java超前了15年，那個(gè)時(shí)候市場(chǎng)還沒(méi)有做好使用這些技術(shù)的準(zhǔn)備。不過(guò)，從1999年以來(lái)的那些技術(shù)在今天仍然適用。我們并沒(méi)有重新造輪子。

在過(guò)去的一年甚至更長(zhǎng)的時(shí)間中，大家總是將Linux容器和微服務(wù)等同看待，這也影響到了在監(jiān)控上的考量。最近，在對(duì)來(lái)年的發(fā)展做出預(yù)測(cè)時(shí)，RisingStack的CTO Péter Márton給出了一些意見(jiàn)。他首先闡述了一些基本理念：

當(dāng)前市面的APM（應(yīng)用性能監(jiān)控，Application Performance Monitoring）解決方案，例如NewRelic和Dynatrace，嚴(yán)重依賴于不同層級(jí)上的儀表展示（Instrumentation），這就是為什么這些產(chǎn)品必須要安裝軟件廠商特定的代理才能采集度量。代理可以采集應(yīng)用的各種度量，包括垃圾回收行為等底層語(yǔ)言特定的度量，以及RPC和數(shù)據(jù)庫(kù)延遲等軟件庫(kù)特定的度量。

Péter進(jìn)而指出，應(yīng)注意不要過(guò)于快速推進(jìn)乃至深入APM路線。他給出了如下的預(yù)測(cè)：

使用軟件廠商特定的代理會(huì)導(dǎo)致一個(gè)問(wèn)題，當(dāng)開(kāi)發(fā)人員開(kāi)始將多種監(jiān)控解決方案和代理一并使用時(shí)，會(huì)丟失當(dāng)前APM解決方案的一些特性。多代理通常意味著對(duì)同一構(gòu)件代碼（code picec）給出多種儀表顯示方式，這可能會(huì)導(dǎo)致不必要的性能開(kāi)銷、虛假的度量，甚至是軟件缺陷。我認(rèn)為在未來(lái)使用軟件廠商特定代理的趨勢(shì)將發(fā)生變化，APM軟件提供商將通過(guò)共同努力提出儀表顯示的開(kāi)放標(biāo)準(zhǔn)。未來(lái)將是獨(dú)立于軟件廠商的時(shí)代，所有價(jià)值來(lái)自于不同的后端和UI特性。

之后，Péter跳轉(zhuǎn)到分布式追蹤（distributed tracing）相關(guān)問(wèn)題上。在他看來(lái)，為了監(jiān)控并調(diào)試所涌現(xiàn)的容器和微服務(wù)，驅(qū)使開(kāi)發(fā)人員提高實(shí)現(xiàn)可觀測(cè)性方法。過(guò)去我們也曾探討過(guò)分布式追蹤技術(shù)，例如Zipkin，以及近期Cindy Sridharan對(duì)可觀測(cè)性的介紹：

日志、指標(biāo)和請(qǐng)求跟蹤是可觀測(cè)性的基礎(chǔ)。日志為數(shù)據(jù)（如指標(biāo)）提供額外的上下文。不過(guò)，日志對(duì)性能的影響也很大。相比之下，指標(biāo)的開(kāi)銷是不變的，而且有利于預(yù)警。總而言之，日志和指標(biāo)可以為觀察單獨(dú)的系統(tǒng)提供方便，但是對(duì)于穿過(guò)多個(gè)系統(tǒng)的請(qǐng)求，很難提供其生命周期的信息。跟蹤提供了跟蹤在各個(gè)系統(tǒng)之間傳遞的請(qǐng)求的能力。

Péter也同意上述觀點(diǎn)。在文章中探討OpenTracing技術(shù)及其重要性之前，他給出了一些例子，說(shuō)明了想要提供的內(nèi)容：

(……）標(biāo)準(zhǔn)，以及用于分布式追蹤儀表顯示的接口，這些接口是獨(dú)立于軟件廠商的。Opentracing提供了一套標(biāo)準(zhǔn)的API，對(duì)代碼情況做儀表顯示，并連接到各種追蹤后端。它也可以在任何時(shí)候?qū)Υa做儀表顯示。不存在任何問(wèn)題，并更改追蹤后端。

他給出了一些在原始技術(shù)中使用OpenTracing的例子，特別是從Node.js開(kāi)發(fā)的角度。在文章結(jié)尾處，他作出了一個(gè)強(qiáng)調(diào)聲明，也可以說(shuō)是一個(gè)請(qǐng)求：“我希望將來(lái)會(huì)有越來(lái)越多的標(biāo)準(zhǔn)化儀表顯示解決方案，也希望有一天，所有的APM軟件廠商能共同努力，提供最好的軟件廠商獨(dú)立的代理”

但是，文章中更多內(nèi)容是對(duì)OpenTracing的介紹。文中介紹了OpenTracing是如何與ElasticSearch和Prometheus一起工作的，其中給出一些例子和展示圖。正如Péter所指出的，這些例子顯示了OpenTracing在架構(gòu)拓?fù)淇梢暬系膹?qiáng)大功能，有助于理解發(fā)生問(wèn)題時(shí)的相關(guān)情況。進(jìn)一步，文中引用了RisingStack的一個(gè)Node.js的Metrics Tracer項(xiàng)目。據(jù)Péter介紹，該項(xiàng)目可用于：

（……）基于這些度量信息，對(duì)整體拓?fù)浣Y(jié)果做逆向工程，并可視化各服務(wù)間的依賴關(guān)系。從這些度量中，我們可以獲得微服務(wù)架構(gòu)中應(yīng)用和數(shù)據(jù)庫(kù)間通量和延遲的相關(guān)信息。

在2016年早期，我們?cè)?ldquo;對(duì)大規(guī)模容器進(jìn)行監(jiān)控所面臨的挑戰(zhàn)”問(wèn)題訪談了部分人士。當(dāng)時(shí)就如何理解和使用追蹤所采集數(shù)據(jù)方面的問(wèn)題，Dynatrace的首席技術(shù)戰(zhàn)略師Alois Reitbauer給出了以下觀點(diǎn)：

（……）每個(gè)人都必須了解這些監(jiān)控?cái)?shù)據(jù)。這也是為什么我們花費(fèi)了大量時(shí)間以創(chuàng)建自解釋的信息圖表，讓每個(gè)人都能夠其中的意義。另一個(gè)關(guān)鍵需求是對(duì)異常情況的檢測(cè)。由于系統(tǒng)的巨大規(guī)模，沒(méi)有任何人能夠做到手動(dòng)查看所有數(shù)字。因此，監(jiān)控系統(tǒng)必須了解什么是正常的行為，并當(dāng)系統(tǒng)的行為出現(xiàn)異常時(shí)進(jìn)行提示。最后一個(gè)方面在于具備上下文的語(yǔ)義信息。舉例來(lái)說(shuō)，監(jiān)控系統(tǒng)需要“理解”指標(biāo)所代表的意義，以及它與其他指標(biāo)的關(guān)聯(lián)。我們需要了解整個(gè)應(yīng)用中的所有依賴，將這此信息用于問(wèn)題的分析。

在文章最后，Péter總結(jié)并給出了如下預(yù)測(cè)：

要使微服務(wù)的監(jiān)控和觀測(cè)性更上一層樓，并步入下一代APM工具的時(shí)代，需要給出一種開(kāi)放的、獨(dú)立于軟件廠商的儀表顯示標(biāo)準(zhǔn)，正如OpenTracing那樣。該新標(biāo)準(zhǔn)需應(yīng)用于APM軟件廠商、服務(wù)提供商和開(kāi)源軟件維護(hù)者。