微服务项目技术架构
 
云原生下一步的发展路径分析
 
 
【摘要】云下一步发展的目标就是让上层应用和业务意识不到云的存在。云原生的下一步发展就是朝这个方向发展。
援引某厂商的说法，云原生已经进入2.0时代，上云也从资源上云进一步向应用上云和业务上云升级，推动企业数字化转型和智能升级。还有一个形象的说法可以概括上述观点，云原生让企业云化从“ON Cloud”走向“IN Cloud”。
一、缘起应用架构演进
我们都知道，商业模式决定了产品形态，产品决定了研发模式，研发模式又决定了需要采用什么样的技术。纵观这些年企业应用架构的发展，我们经历了传统应用时代、互联网应用时代和数字化转型应用时代，所处的时代不同引发的需求也不同，由此带来对技术的要求自然也不同。
传统的应用需求是相对固定的，通常以项目化运作，用户的访问量可以预测，容量是有限的，对停开机的要求也没有那么严格。所对应的应用架构一般是单体应用和垂直架构，集成方式也多是直连模式或者网状集成。
互联网应用的特征是需求持续发展，产品化而非项目制，用户量并非线性，往往会有陡增陡降。应用架构多是SOA架构，集成方式一般通过ESB等应用集成平台。
处在这样一个数字化转型的时代，我们的业务边界和业务活动是完全不可预知的，即便是对于互联公司都是巨大的挑战，要求快速地尝试、快速探测、快速的感知，应用是服务化的方式提供，业务敏捷性前提之下，对技术体系的持续发布、分布式海量并发、灰度发布和线上
测试都是基本诉求。业务的敏捷性持续发布，应用平台的弹性诉求，商业环境的变化，这是整个云原生产生的时代背景。
二、微服务是一个躲不开的话题
首先，我们需要再次明确一个概念。微服务，不是一种技术而是一种软件架构模式和方法，是一种基于将应用程序构建为小型服务集合的软件开发体系结构方法。从某种程度上说，微服务是单体应用的对立面。从本质上来讲，微服务就是把单体应用从一个巨型的应用拆分成数个更微小的服务，协作完成原来单体应用所提供的等效业务服务。单体应用跟资源之间是一对一的紧耦合关系，单体应用的协同也都是一些内部协同，不存在外部的动态依赖。而当我们转换到微服务之后，服务与服务之间会有依赖关系，依赖关系会变成网状，变得复杂起来。
容器化的出现，一定程度上带动了微服务架构。架构演化从单体式应用到分布式，再从分布式架构到云原生架构，微服务在其中有着不可或缺的角。
微服务体系和云原生架构的组成部分有各自的部分，也有重叠的部分。
首先，微服务体系会涉及业务体系部分，从业务需求出发，采用DDD等理念搭建微服务的业务模型，这部分其实并不在云原生架构体系里面。
同样，云原生是构建在新型基础设施上面的，所谓新型基础设施是结合了分布式云和不可变原则的，微服务更强调外部依赖，并不涉及基础设施部分。
微服务跟云原生共同关注的内容，其实是技术体系和管理体系两部分，其中技术体系主要是涉及微服务技术架构、集成工具，，面向云原生更多强调云平台和和容器化能力。管理体系更关注从业务角度如何支撑和获取管理支持，比如研发过程中的敏捷、研发规范和度量，运维过程的CI\CD等。
从微服务架构的思想出发，微服务架构、DevOps 和容器技术天然地走到了一块儿，构成了云原生应用架构的雏形。
三、云原生的基本理解
1、基本概念
云原生从字面意思上来看可以分成云和原生两个部分。云原生的定义，CNCF是这样说的，“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。”
2、基本特征
CNCF给出了云原生应用的三大特征：
容器化封装：以容器为基础，提高整体开发水平，形成代码和组件重用，简化云原生应用程序的维护。在容器中运行应用程序和进程，并作为应用程序部署的独立单元，实现高水平资源隔离。
动态管理：通过集中式的编排调度系统来动态的管理和调度。
面向微服务：明确服务间的依赖，互相解耦。
云原生包含了一组应用的模式，用于帮助企业快速，持续，可靠，规模化地交付业务软件。云原生由微服务架构，DevOps 和以容器为代表的敏捷基础架构组成。