架构演化：云原生时代正式开启
张亮 当当架构部负责人。主要负责分布式中间件及私有云平台的搭建。乐于分享，拥抱开源，主导两个自研项目Elastic-Job和Sharding-JDBC都已正式开源。擅长以Java为主的分布式架构以及以Mesos为主的云平台方向，推崇代码优雅化，对于如何编写出具有强表现力的代码有深入研究。
随着互联网大规模地接入，基于流量点击盈利的Web 1.0业务模式转变为由用户主导而生成内容的互联网产品，即Web 2.0业务模式。互联网应用系统所需处理的访问量和数据量均急速增长，后端技术架构也因此面临着巨大的挑战。
这一阶段的互联网后端架构大多由单体式应用架构渐渐转向更加灵活的分布式应用架构；而企业级架构由于功能复杂且并未出现明显的系统瓶颈，因而并未跟进。后端开发由单一技术栈渐渐区分开来，越来越明显地划分为企业级开发和互联网开发。企业级开发和互联网开发的差别不仅在于技术栈，也在于工作模式，对质量的追求与对效率的要求成为两个阵营的分水岭。
在技术方面，为了应对更加巨大的规模，单纯的分布式系统已经难于驾驭。技术圈也因此契机开启了一个概念爆发的时代——SOA、DevOps、容器、CI\CD、微服务、服务网格等应运而生， Docker、Kubernetes、Mesos、Spring Cloud、gPRC等一系列产品的出现标志着云时代真正到来。
1.互联网架构变迁
互联网应用的业务特征决定它和企业级应用不同，主要有以下几个问题存在：海量用户、产品迭代迅速、7*24不间断服务、流量突增、业务组合复杂。以上述最后一点为例，电商业务系统架构非常复杂，一个粗略的示意图如下。
由于互联网行业业务特征的特殊性以及势不可挡的扩张速度，相应底层支撑的技术挑战也越来越大。由规模而衍生的问题包括海量数据、响应迟缓、稳定性差、伸缩性差、系统繁多和开发困难等。因此针对这些问题，互联网的技术架构也在逐渐的转变，向集中式、分布式、云平台的方向演进。
从集中式到分布式架构
集中式架构又叫单体式架构，在Web2.0模式并未大规模兴起时十分流行。后来，基于Web应用的B/S（Browser/Server）架构逐渐取代了基于桌面应用的C/S（Client/Server）架构。B/S架构的后端系统大都采用集中式架构，它当时以优雅的分层设计，统一了服务器后端的开发领域。
从分布式到云原生架构
随着虚拟化技术的成熟和分布式架构的普及，用来部署、管理和运行应用的云平台被越来越多地提及。IaaS、PaaS和SaaS是云计算的3种基本服务类型。容器的出现，使原有的基于OpenStack的云主机应用彻底转变为更加灵活和轻量的容器+编排调度的云平台应用。
2.云原生
云计算的本质是按需分配资源和弹性计算。顾名思义，
云原生应用，即指专门为在云平台部署和运行而设计的应用。
云原生应用并非完全颠覆传统的应用设计模式，而是将传统应用模式提升和修改，让其更加适合在云平台上运行。大部分传统应用即使不做任何改动也可以在基于Linux操作系统内核的云平台运行，但是这种仅以能够部署和能够运行为目的的模式只能将云主机当作物理机一样使用，不能真正的利用云平台所带来的能力。
让应用能够利用云平台实现资源按需使用和弹性伸缩，是云原生应用重点关注的地方。
云原生的本质是一种模式，它要求云原生应用满足可用性和伸缩性，具备自动化部署和管理的能力，可随处运行，并且能够通过持续集成、持续交付工具提升研发、测试与发布的效率。
2015年，由Google提议创立的CNCF（Cloud Native Computing Foundation）正式成立，并且发布其标志性产品Kubernetes 1.0，不少有价值的云原生项目也随之诞生。CNCF将云原生的生态圈划分为5层，分别是应用定义与开发层、编排与治理层、运行层、供应保障层和基础设施层。同时，CNCF又纵向拆分出了观察与分析层服务于所有层的软件，将这些层的所有功能整合起来即为一个完善的云平台服务产品。
应用定义与开发层
应用在开发节点时需要关注这一部分，它的技术栈与单体式开发并无二致。在分层结构出现之前的混沌时代，为云平台定制的应用也可以在这一层通过框架实现。但是在层次结构划分清楚后，这一层的最佳实践是集中关注业务应用开发语言、框架及其所需的API，主要包括数据库、数据仓库、流式处理、开发语言、开发框架、源代码管理、依赖打包工具、持续集成\持续交付。
编排与治理层
编排与治理层将业务应用框架与云原生所需的弹性、分片、调度、治理等功能独立出来，形成独立的一层。这种划分方式更加清晰地将云原生应用管理起来，即是否为云原生架构对业务开发工程师来说完全透明，而云原生中间件工程师也无须过多关注业务。相对来说，CNCF的产品更多的集中在这一层。这是云原生产品比较容易发力的部分，主要包括调度与编排、分布式协调与服务发现、服务治理。
运行层
云原生的应用并不是直接运行在物理服务器上的，而是在它们之上再构建一层，用于轻量、灵活、海量的运行实例。云原生应用需要重新定义操作系统、进程与网络，主要包括云原生操作系统、云原生存储、容器、云原生网络。
供应保障层
供应保障层提供对宿主机和容器本身的供应和保障。对于宿主机管理工具而言，虽然云原生应用时跑在一个相互隔离的由调度系统掌控的容器环境中，但它们最终仍然运行在真正的物理服务器之上。因此，管理工具需要能够将Docker、Mesos、Kubernetes等软件自动的安装和配置在应用运行的宿主机上。另外，安全漏洞一直存在与程序的世界。升级为容器之后，此类安全威胁仍然存在，因此需要能够发现容器中可能存在的安全问题的工具，称之为安全镜像。
基础设施层
用于提供物理服务器的云厂商。如AWS、Azure、OpenStack、阿里云等。这一层并不在CNCF的涉及范畴。
下面再来看一下纵向分层的涵盖的内容。纵向分层以另一个维度描述云原生应用，观察与分析是每一层都需要的功能，平台则是将每一层功能组合起来的整体解决方案。
观察与分析
①监控
监控包括对物理服务器指标进行采集与报警的工具，对容器指标进行采集的工具，以及存储海量采集信息的时间序列数据库。通过采集、存储、分析、报警的流程自动将系统状态通知系统责任人处理或定期分析。
②日志
由于云原生应用是无状态的，因此不应将日志写入本地磁盘，而是应该写入日志中心。借助Fluentd 、Flume、FileBeat、Logstash等工具将标准输出采集并输入至其他流，再由这些工具将其通过各种缓冲的管道处理写入日志中心。
③追踪
云原生应用运行实例多，应用调用复杂，因此一旦系统响应变慢，难于定位问题。因此需要提供一套服务之间的调用链以及服务内部的调用栈梳理和分析的解决方案。
平台
基于云的整合平台是目前各个云公司所着力打造的产品，比较知名的有围绕Mesos打造的DC/OS，以及可以整合Mesos和Kubernetes的Rancher平台等。
上面提到的技术只是云原生技术的冰山一角，无论是开源还是商业产品，优秀的组件和解决方案数不胜数。下图是CNCF官方提供的一张全景图，仍在不断更新中。
CNCF目前所涵盖的项目包括Kubernetes、CoreDNS、Linkerd、gRPC、Containerd、rkt、CNI、Prometheus、fluentd和OpenTracing。这其中既有Kubernetes、gRPC、Prometheus这样的优秀产品，也有CNI、OpenTracing这样的标准协议。CNCF的发力也主要集中在编排与治理层、运行层和观察与分析三部分。
云原生可以有不同实现方式，但它的本质是可以弹性的利用云平台的资源。无论是通过“应用程序 + 云原生框架 + 自动化运维”的方式实现云原生，还是通过“应用程序 + 调度平台 + 容器 + 治理”的方式实现云原生，都是可以的。但是通过CNCF的分层模型将每一层划分得更加清晰，透明化每一层的职责，这是更优雅的实现方案。
本文摘自博文视点2018年开年大戏——张亮作品：《云原生分布式中间件架构》，深度揭秘Elastic-Job&Sharding-JDBC！