高可用架构：陈皓，您好，很多读者应该都听说您离职创业了，但是还不太清楚您做的产品和要解决的问题，能否介绍一下？
陈皓：为企业提供软件架构稳定性和性能的关键技术。面对现在高速发展互联网规模的成长，企业的应用架构在稳定性和可用性上有大的挑战，大公司的架构无法惠及到其它公司，而且技术人才招聘的成本越来越高，所以，企业在发展过程中需要投入并花费大量的人力和精力来研发很多的支撑且非功能性的软件，这些东西一下子就拉慢了企业的发展速度。
所以我主要给企业提供相应的技术产品，目前，包括一个流量调度的 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 是有领导力的，是可以推动一些工程师文化和领导技术潮流。嗯，你们不是媒体，一定行的。