高可用架構：陳皓，您好，很多讀者應該都聽說您離職創業了，但是還不太清楚您做的產品和要解決的問題，能否介紹一下？

陳皓：為企業提供軟件架構穩定性和性能的關鍵技術。面對現在高速發展互聯網規模的成長，企業的應用架構在穩定性和可用性上有大的挑戰，大公司的架構無法惠及到其它公司，而且技術人才招聘的成本越來越高，所以，企業在發展過程中需要投入并花費大量的人力和精力來研發很多的支撐且非功能性的軟件，這些東西一下子就拉慢了企業的發展速度。

所以我主要給企業提供相應的技術產品，目前，包括一個流量調度的 API 網關來扛高并發流量，一個 Cloud Native 的服務調度軟件來完成服務的伸縮編排和故障恢復，一個全棧軟件監控的 APM 軟件用來收集并關聯架構中所有軟件的信息以及做為調度決策，三者相輔相成，讓企業的應用服務架構更容易地擴展和運維，降低開發成本，提高運維效率，并可以快速地提升企業軟件架構的穩定性和可用性。

?

高可用架構：你們的產品和微服務有什么關系么？

陳皓：老實說，我的產品和微服務即有關系也沒有關系，我的產品并不關心是不是微服務的架構。

我的產品只關心整體架構的穩定性和性能，那怕用戶的架構是一個單體架構，我的產品也可以幫助用戶提高可用性和性能。當然，要達到質的提高，分布式架構是必需要走的路，而分布式架構最大的問題就是會讓架構管理和運維的復雜度的呈級數性提升，此時，我的產品同樣可以解決分布式架構所帶來的管理和運維問題，當然，我的產品不是銀彈，也只能在一定場景下解決相關的問題，我針對的場景就是高并發，高可用性的自動化運維相關相關的問題。我并不能幫用戶解決其它的分布式的問題，比如分布式事務相關的問題。

微服務應該是分布式服務化中的一個更細粒度的形式，所以，我的產品只是可以用于微服務式的架構，在不久的未來我還會支持像 AWS Lambda 這樣的函數級的微服務。

然而，我不會刻意的把自己的產品歸類為與微服務相關的。因為我的產品其實屬于 PaaS 的調度層，而且可以像樂高玩具一樣靈活的組合，所以，可以用于各種主流的架構。

?

高可用架構：微服務是一種通用的架構方式還是只是適合應用發展到某個階段的架構？這個問題現在也有許多爭論，比如說這篇文章《About When Not to Do Microservices (http://blog.christianposta.com/microservices/when-not-to-do-microservices/)》，您有什么看法？

其一，這個世界不可能有通用架構。因為你不可能什么都要的，一切都是 trade-off，都是翹翹板。你要這頭，就不能要那頭。任何軟件設計都需要明確地定義自己要什么不要什么，任何軟件設計都會有缺陷，這個世界不存在完全完美的事情。就像汽車一樣，你造不出一輛可以高速行駛運動型的、還能拉數十噸貨載重型的，以及可以在山地和淺灘上越野型的汽車。其二，對于一個問題通常來說也不會只存在一個標準答案，解法多種多樣，因為，關鍵看你關注于什么。其三，任何技術，任何設計都有他使用的地方和場景，所以，脫離了場景來談軟件設計或是架構其實是相關不科學的，這是紙上談兵和理論派的做法，而不是工程師的做法，工程師解決問題的第一步一定是先了解要解決什么樣的問題，這個問題的本質是什么問題，這個問題可不可以被簡化和抽象，之后才會根據需求和場景來挑選合適正確的技術。

關于微服務的優勢是開發快、部署快、隔離性好、功能擴展也方便，但是集成測試、運維、和服務管理就麻煩大了。所以，對于微服務來說，如果沒有一個好的微服務的 PaaS 平臺，這事還真不好玩，尤其是服務越來越多的情況下。對于一個企業來說，我倒不覺得要發展到什么程度才會用微服務，我倒覺得這個企業是個什么性質的企業才是比較重要的。如果這個企業想做平臺，想把自己的服務或是相關的能力開放出去，可以讓其它第三方對最終用戶的軟件功能進行各種不同的定制化，那么玩微服務是個比較好的方式，否則似乎也沒有太多必要。

關于《About When Not to Do Microservices (http://blog.christianposta.com/microservices/when-not-to-do-microservices/)》文章中所說的，快速試錯的最好用單體架構，而需要穩步發展的可以考慮微服務，我覺得有一定道理，但是我覺得作者沒有抓住軟件設計的本質。

程序的本質是：控制邏輯 + 業務邏輯。控制邏輯是和業務不相干的邏輯，是我們如何控制程序執行，是并行的還是串行的，是分布式的還是單體的，是異步的還是同步的，是用循環還是用遞歸，是用 NoSQL 還是用 RDBMS……，所有的非功能的東西都是控制上的邏輯。而業務邏輯則是實實在在的業務邏輯，是我們要解決的業務問題。這就好像我們的程序中，有一些變量是用來處理業務的，但也有好多變量是用來控制程序的流轉的，這兩種變理共同造就了整個程序的復雜度。一個軟件的復雜度的上限是業務邏輯，如果業務邏輯太復雜，你是不可能用控制邏輯來簡化的，而下限是控制邏輯的復雜度。一個好的系統一定是會控制邏輯和業務邏輯能分離的比較漂亮的，否則就會亂成一團。

基于這個本質，我覺得，微服務其實屬于控制邏輯的范疇，如果一個業務的邏輯非常復雜，你是不可能通過微服務化來降低這個復雜度的，而強行使用微服務化，只會讓你的控制邏輯和業務邏輯交織不堪，最終導致整體的復雜度奇高無比。所以，如果你不能把業務邏輯簡化或模塊化，那么你會覺得微服務也沒有幫你什么。能做的也就是只能把一些共用的東西抽解出來形成可以復用的服務，或是把某個業務功能或流程整體服務化。僅此而已。

雖然如此，但是我覺得微服務是趨勢，因為這個是 PaaS 的一個關鍵技術，而我個人覺得，PaaS 的重要程度在過去的日子里一直在被低估中，而我已經看到 PaaS 層正在一點一點地崛起，很多走在前面的公司越來越重視這一層。

?

高可用架構：創業這一年，有客戶遇到關于微服務的問題么？您覺得微服務要落地，最大的困難是什么？

陳皓：沒有見過真正的完全是微服務的架構，只見過為數不多的部分微服務化，更多的還是應用服務化，數據庫還是單體。

見過的微服務的最大的問題有這么幾個：1）分布式事務，2）服務依賴的問題，3）服務太多，導致前端一個頁面，需要調好多服務接口才能完整地取到數據，增加響應時間。

微服務要落地，最大的困難是：1）傳統的系統改造，2）要非常強的業務架構能力，3) 一個好的 DevOps 和線上自動化運維調度的 PaaS 支持。4）公司的組織架構和人員能力的的重構。

?

高可用架構：Serverless 和 FaaS 是技術領域的一個新熱點，您怎么看這個技術？

陳皓：從技術的角度上來說，我太喜歡這么炫酷的技術了。但是，我理智，技術不是用來炫酷的，如果一個技術不能解決一些實際的問題，那么這個技術也就是一個花瓶技術。對于像 AWS Lambda 這樣的 Serverless 和 Functional Service 的技術，我覺得是有應用空間的。

今天正好和一個朋友聊起了這個技術。這個朋友在國外，他們的公司是 AWS 的重度用戶，他們是做大數相關的事，幾乎全部使用 AWS 的相關云服務，而 AWS 也在推廣他們的 Lambda 服務，所以，他們使用了一下 Lambda 服務，發現完美之極， AWS 的 Lambda 服務配合其現有的云服務在開發上真是太方便了，關鍵還很省錢。經由這個事，我覺得，Serverless 和 FaaS 必需要能夠配合現有的其它服務才能玩出比較實際的業務功能，不然，你只能寫幾個 Hello World 的應用罷了。

當然，這是在云端的 Serverless 和 FaaS，因為云端的業務邏輯是比較復雜的，所以，這樣的技術需要很多的支持才有價值。但是，假如這個 function 不是部署在云端呢？如果是部署在邊緣結點上呢，比如像 CDN 這樣的邊緣結點，這事的想像空間就很大了。舉個例子，我希望我的 APP 上的 banner 對于不同地方的用戶展示不同的內容，這個事其實就是一個小函數的事，而且業務邏輯很簡單，是非常適合用 Serverless 和 FaaS 這樣的技術的。

同理，對于比較熱的 IoT 方面的應用，因為設備太多，云端處理起來是非常笨拙而且不實時，而在連緣結點做一些簡單的處理，這樣可以讓設務響應得更快更及時。我個人覺得，這是 Serverless 和 FaaS 的最大的應用場景——邊緣計算。

?

高可用架構：如果樂觀的估計，您覺得這波 Serverless/FaaS 技術浪潮影響的邊界最大到哪里？

如果說 Serverless/FaaS 的最大應用場景是 IoT 的話，那么這可能會非常恐怖。人類已經聯了所有的電腦和所有的手機，現在就差所有的設備了，如果所有的設備都被聯上來了，那么，這個世界會變成什么樣我也想像不到了。20 年前，從來沒有想到過今天有很多很多事都可以通過網絡搞定了。那么 20 年后，這個世界會變成什么樣，我估計不出來，但是一定會比今天更精彩，對于未來的這種未知，我的心里在只有敬畏和激動。

?

高可用架構：最后，經過這一年的創業，有什么認知是創業前沒想到的，或者認知產生了很大變化的，可以給大家分享么？

沒有想到的有下面這幾個方面（大體來講）：

1）眼界極大的開闊了， 看到各行各業的不同的玩法，讓我感覺一下并行著有了很多份人生經歷。朋友圈也擴大了很多。

2）對國內整體的商業情況和問題有了更為全面的了解，這個還在不斷更新中。

3) 創業中，要做的事要解決的問題實在是太多了，我預見到了有很多，但完全沒有想到有這么多。

4）我對我自己的某些能力嚴重低估了，同時也高估了一些能力。

認識改變最大的是，進入了另外一個圈子，這個圈子里的人都是非常喜歡折騰的，他們的思維方式和打工的完全不一樣，我覺得這個圈子讓我收獲太多了，信息量太大了，我還用了一個從來沒有人用過的方式創業，就是完全的遠程團隊，收獲良多。這一年的創業是我在公司里 3-5 年的收獲。這個過程比較累，而且可能未來不一定能行，但是我很充實，也很滿足，就算以后再要回到公司工作，我覺得我能勝任的職位實在是太多了，而能推動事的能力也一定比之前強太多了。這其中的感受實在是太多，竟然讓我不知道怎么說出來……總體來說，這個體驗對我來說是有價值的。

?

高可用架構：最后，您這是第二次出席 GIAC 大會了，您對 GIAC 有什么寄語么？

陳皓：希望 GIAC 不是簡簡單單的辦會，我希望 GIAC 是有領導力的，是可以推動一些工程師文化和領導技術潮流。嗯，你們不是媒體，一定行的。

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的左耳朵耗子论微服务 Serverless 及 FaaS | GIAC 访谈的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。