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

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

所以我主要給企業提供相應的技術產品，目前，包括一個流量排程的 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 是有領導力的，是可以推動一些工程師文化和領導技術潮流。嗯，你們不是媒體，一定行的。