2019 年，很多人会对“云原生”充满了疑惑甚至误解。这想必也是为何我们一直能够在不同场合听到关于云原生的各种不同定义的原因所在。有人说，云原生就是 Kubernetes 和容器；也有人说，云原生就是“弹性可扩展”；还有人说，云原生就是 Serverless；而后来，有人干脆做出判断：云原生本身就是“哈姆雷特”，因为每个人的理解都不一样。用友开发者大赛（2020.diwork.com/index.html）借赛事的举办对此进行了更为深入的研究和解读。
实际上，自从这个关键词被 CNCF 和 Kubernetes 技术生态“借用”之初，云原生的意义和内涵就是非常确定的。在这个生态当中，云原生的本质是一系列最佳实践的结合；更详细的说，云原生为实践者指定了一条低心智负担的，能够以可扩展、可复制的方式最大化地利用云的能力、发挥云的价值的最佳路径。
所以说，云原生并不指代某个开源项目或者某种技术，它是一套指导软件与基础设施架构设计的思想。这种思想，以一言以蔽之，就是“以应用为中心”。正是因为以应用为中心，云原生技术体系才会无限强调让基础设施能更好的配合应用，以更高效的方式为应用“输送”基础设施能力，而不是反其道而行之。
而相应的，Kubernetes、Docker、Operator 等在云原生生态中起到关键作用的开源项目，就是让这种思想落地的技术手段。以应用为中心，是指导整个云原生生态和 Kubernetes 项目蓬勃发展至今的重要主线。
2020 年，随着容器、尤其是 Kubernetes 的迅猛发展，CNCF 基于 Kubernetes 这样一个“种子”迅速构建起来一个以数百个开源项目组成的庞大生态，使得云原生的落地趋势越来越清晰：以容器的形态落地，把“以应用为中心”进行到底。
DDD（领域驱动设计）的思想发端于 2004 年，在过去的十余年时间中一直不温不火，直到最近两年才得到越来越多的关注度。有人说，正是托微服务的福，DDD 才有了流行的土壤。实际上，目前微服务的划分方法里全球共识的就是 DDD，但 DDD 的核心思想并不仅仅局限于微服务本身。因为微服务是一种架构风格，而 DDD 是一种思想。微服务定义的九大核心特质，跟 DDD 的原则是完全一致的，这在某种程度上也是业界愿意在微服务上下文中采用 DDD 方法和实践的原因。
虽然 DDD 的关注度日渐提升，但在实践过程中，也遇到了敏捷开发式的尴尬：如何调整组织架构以适配DDD？过去业界提到敏捷开发，都说对个体的要求太高，但实际上并不是。表面上看敏捷对开发人员的技能要求高，实际上是因为敏捷开发要求调整组织架构，很多人不愿意动，因此业务和技术协作上的问题很难解决。
DDD 面临的困境同样如此，在过去，技术这条线的划分可能是开发一部、开发二部，业务这条线的划分可能是业务一线、业务二线。但 DDD 的划分理念是从业务角度划分成领域，领域再划成服务，落地的时候采用微服务架构，以前的划分方式完全适配不了，所以直接造成 DDD 落地难的阻碍也是组织结构。
具体表现就是协作不起来，各条线相互甩锅，领导抱怨团队人员能力不够。可以预见，随着微服务和中台思想的持续升温，2020 年 DDD 将会变得更加流行，但由此带来的问题也会愈加凸显。
2018 年至今，Service Mesh 的热度直线上升，而随着 Kubernetes 生态体系的逐渐建立和完善，基于 Kubernetes 应用程序的规模和复杂性将增加，Service Mesh 将成为有效管理那些应用程序所必需的一切。企业对其的需求将会快速增长。
我们认为，2020 年 Istio 作为控制平面的一种技术实现仍将在 Service Mesh 领域扮演核心角色。Istio 获得业界广泛关注的原因，在于背靠 Google 公司的内部工程实践，以及对工程实践的再思考和重新提炼。而在国内也有阿里巴巴等大玩家在参与其中。未来市场上可能还有其他竞争者的空间，但市场的整合将于 2020 年开始。
从长远来看，我们很可能会看到类似 Kubernetes 的情况，其中出现了赢家，公司开始标准化那个赢家。目前来看，业界正在围绕 Istio 建立生态，Istio 似乎最有可能成为事实上的 Service Mesh。
2019 年 Service Mesh 的解决方案用例较为单一，展望 2020 年，相信会有更多的公司通过实践而对 Service Mesh 的价值更有体感，通过创造更多的成功用户故事、案例而加速 Service Mesh 的普及。也许，2020 年将成为 Service Mesh 技术的普及年。
文章参考用友研究院、用友开发者大赛和YonBuider开发中心资料
