业界对CloudNative的解读很多，我们做的东西也相对基础和通用，能够用在多种不同的场景，并提供各式各样的技术方案，所以，大家都感觉我们做的东西太多，什么都在做。好多人会时不时的问我们到底在做什么，解决什么问题，以及我们的产品的核心技术是什么？今天我们把大家一直以来的疑问汇总一下，做个十问FAQ。
关于用户的核心问题，在这个时代，从业务的发展趋势来讲，整个数字化进程正在从“企业侧”转型到“用户侧”。
所以，满足用户侧的数字化就需求底层的IT基础设施满足如下的这几个特性：
所以，这一整套的系统，并不是可以简单的用一些开源软件或是找几个系统集成商就可以搭建出来的，其需要有自顶向下的设计和规划，以及大量专业的软件技术和方案构成，这并不是一般企业可以完成的。
MegaEase的方向是CloudNative的方向，CloudNative就是把云计算的核心技术拿出来直接无缝地集成到应用层，让我们的应用Natively就是Cloud。这个时候，对于用户来说，无论上不上云都已经是云了。
举个经典的例子，Google上世纪90年代把自己的搜索引擎架在了廉价且不稳定的x86+Linux的机器上（连服务器都不算），整个搜索引擎依然可以稳定的运行。这是因为软件架构做得好。所以，Google因为自己的这个实践向业内发布了三篇分布式的论文，而这三篇论文直接引领了整个技术架构的变迁。从这个例子，我们可以看到，对于云计算来说，软件和应用架构才是真正给企业带来能力的重要特性。用一句比较夸张的话来说，只要软件架构做的好，基础资源就变的不是很重要了。
所以，CloudNative所带来的时代变革是——把云计算从以前以资源型的方式转向了以应用和服务的方向。所以，像Serverless、ServiceMesh、Kubernetes、APIManagment、MicroService，整体架构观测型……全部都是在说应用服务层的事，而不再是基础资源了。
但是，CloudNative的技术是非常的繁杂纷乱，而且门槛也比较高，而且在实际应用上离企业的需求和痛点还是有一定的差距。（注：下面这的技术图并不完整）
然而，对于用户来说，除了纷乱复杂之外，还会发现，用上了这些技术后，还是没有解决他们的问题，而且还引入了更多的新的问题。依然不能高并发，开发速度还是不够快，运维更复杂了，故障也更多了，感觉成本还更高了……
怎么把这些技术零件拼装起来，而且能够打造成一个企业级的架构，这个是MegaEase过去几年一直在努力积累和沉积的。
一个好的系统架构的核心就是要有统一精良设计的控制和调度系统，这个是架构和系统集成的本质不同。
系统集成几乎所有的软件厂商都可以完成，但是云计算和云原生架构则并不是。几乎所有的公司都可以用CloudNative来标榜自己，但是只有少数的公司才会拿真正的技术能力来标榜自己。
MegaEase更多的是用技术能力来标榜自己，比如：一行代码不改做秒杀，我们可以支持用户超高并发的场景。我们可以让用户获得更快的故障处理能力，可以让用户进行全链路的灰度发布和完美的无侵入式的生产线全链路压测，以及真正可用的灰度发布系统，高可用的中间件架构、跨数据中心的多活和部署系统……
我们的核心技术能力和优势有这么几点：
通过这些技术，我们可以很容易地为用户建立一套先进的技术架构和基础设施，而企业用户利用这些技术架构和基础设施，可以很容易在上面做面向用户侧数字化的开发，而无需关心整个系统架构所带来的复杂性，使得用户一行代码不改拥有CloudNative的能力。
有很多不一样，最重要的是下面两个点：
EaseMesh拥有真正意义上东西向流量调度（真正的跨服务，端到端），这意味着依托在EaseMesh的成熟的东西向流量调度上，可以让用户用一行代码不改直接有服务治理、服务监控、调用链跟踪、流量着色、一行代码不改做真正的基于用户侧属性的灰度发布，以及一行代码不改完美的全链路压力测式等高级的企业级的解决方案。
EaseMesh是完全兼容Java技术栈的，而现有的ServiceMesh则和用户的现行成熟方案冲突，需要用户去做适配和迁移，并放弃这样的技术栈。
EaseMesh和EaseMonitor可以完美整合，打造了一个真正面向服务的体检和急诊特性的可观测性能力。（具体可以参考EaseMonitor章节的描述）这些都是是市场一些ServiceMesh方案完全不可比拟的。
下图是一个对比较图表，比较了成熟的Java企业级的一个技术栈的对比。
我们可以看到，现有的ServiceMesh基本上是完全基于Kubernetes的架构，这会逼着用户做在架构上做一个二选一。而EaseMesh则不需要，我们是完全兼容JavaSpringCloud的ServiceMesh，可以让用户同时拥有两边的优势。
下面这个表格是SpringCloud生态和现有的ServiceMesh生态的子系统对比。
子系统
SpringCloud生态系统
ServiceMesh生态系统
服务注册和发现
开发简单方便，只需一个简单的注解。支持不同的服务注册系统。开发者很容易在本地搭建一个开发环境来完成编码和调试。
基于K8s的Service机制，提供自己的Registry来同步数据。开发者需要了解Kubernetes，开发环境不易搭建。
弹性和容错
Resilience4j的官方集成提供了完整的容错机制。但是服务需要与SDK集成。
通过使用边车方式的架构，它是一种非侵入式容错机制，对服务完全透明。
可观测性
SpringCloud内置、springmirco-meter、zipkin等。所有service-inside指标、跟踪和日志都可以轻松收集，并且通过javaagent字节码注入的方式，对开发人员完全透明。
通过sidecar机制，它可以监控入口或出口通信。如果没有服务内部的可观察性，服务跟踪可能是不完整的。
流量调度
SpringCloud只有一个非常基本的流量调度。例如，负载均衡基于Ribbon（从最新版本中移除）
更多的流量调度方案，金丝雀部署，蓝绿都能优雅的完成。
EaseMonitor不仅仅只是一个调用链跟踪系统，其主要是做整个技术架构的“体验”和“急诊”，对整个分布式云原生架构做整体的可观测性。可以算是一个“统一监控系统”。
对于云原生的整体可观测性有如下的一些重点：
需要解决的问题是
几个核心思想
所以，EaseMonitor主要解决的数据关键和数据分析。而不是一个个割裂的监控系统。
EaseMonitor底层使用的组件，如数据采集telegraf/filebeat，数据总线Kafka，时序数据库InflexDB/Promethus，搜索数据库ElasticSearch，调用链协议Zipkins，都是非常主流和常用的监控协议，用户基本上来说不需要改造基础设施，只需要通过配置修改监控的数据格式，然后，剩下分析，关联，展示，急诊，体验，报警……等的事情就交给EaseMonitor了。
一句话，我们主要做有精良设计的统一监控系统，不是一个系统集成出来的东西。
先说一下在生产环境做全链接压力测试的的难题。其最重要的就是——测试数据隔离。在生产线上做测试不能影响到生产业务，所以，你没有办法用生产的数据做测试，所以，你需要先伪造很多测试数据。所以，
这些技术难题都给在生产线上做压力测试带来了非常大的难题——要有非常大的改造成本。
EaseLoad完全是一个我们在做ServiceMesh的一个副产品。我们在做EaseMesh的时候，发现通过其中的无侵入式技术，我们可以非常完美的做到在生产线上的全链路压力测试，这其中完全不需要改造代码，只需要增加一定的服务器资源，对一些服务进行无侵入式的Mock，在测试完后，可以把数据和资源完美销毁，完全符合云计算和云原生的特征。
下面是一个示意图
我们可以看到EaseMesh进行了以下的工作：
在不改变任何用户源代码的情况下，EaseMesh为生产中的性能测试带来了完美的解决方案，它是方便、简单和安全的。
如果用户使用k8s系统的话，会获得最佳的工程能力。我们认为，不能一味的迁就这些老旧的系统，帮助用户提升工程能力和引领用户升级到更为先进的技术栈上是我们的价值观。所以，如何帮助用户通过K8s来进行更为科学和先进的管理和运维，让用户成长是我们的核心目标。
今天，几乎所有的公司，不分传统还是互联网都已经在尝试或是使用k8s以及云原生架构。所以，这个是技术的行业趋势。我们相信，k8s最终有可能会成为一个基础设施打在操作系统中，让未来的所有需要Cloud技术的企业都无法避开。
对于一些老旧系统，分成两种，一种基本没有什么需求要添加的，这类系统，不动就好了。另一种则有很多需求需要加的，那么我们还是建议使用微服务分布式的架构来重写，因为重写可以获得更快的开发速度，一味的兼容只会导致技术债要还的利息越来越高，未来这个技术债务的利息只会越来越大，用户的在这些系统上的维护成本只会越来高，动作只会越来越慢。软件本身是需要升级的，这些老旧的系统只要还有新的需求，就应该在适时的时候被重构或重写。
如果用户用的是主流开放的技术（比如：JavaSpringboot2.x），那么用户基本上来说是不用改造的，而且我们花了很多心思和精力在零成本改造的技术，我们还要在这条路上精进下去。另外，再配合上“新城区”和“老旧区”的方式来兼容于存量系统，可以让用户更为灵活地按自己的计划进行迁移或改造。
总之，我们所有的技术方案，还有我们的产品设计的第一准则，永远都是尽可能要把改造成本降到最低直到为0。
在近期我们给某个银行的应用做的PoC的测试，用户只花了10几分钟修改了一下配置，然后就顺利接入到我们的系统里了，全栈监控、灰度发度、流量调度、服务治理、弹性伸缩、高可用……一应俱全，用户只是给我们一个jar包，用我们的脚本做成一个Docker镜像就好了，接入就是这么简单。