在大家还在猛刷“三年高考，五年模拟”的时候，我将我写完的SpringBoot项目用Docker部署在Linux上，我现在还记得当时那种兴奋的感觉，不用手动部署项目，不用手动部署Nginx、Redis、MySQL…只需要用Docker拉取对应版本镜像，通过简单的命令就可以完成之前复杂的操作，再加上相关编排工具的加持，简直不要太爽。
再到高考之后，我发现当时已经称霸的k8s+拥有绝对地位Docker+SpringCloud Netflix已经可以满足企业开发，我觉得这一定是风口，你要知道，风来了，猪都会飞，我虽然数理化没学好，但我想做这只猪，这只会飞的猪。
其实，云原生从我当初刚了解的时候，就特别火，而且是一直火，没想到时至今日，才被大家所熟知。
早期，云原生架构有几个特征：
-
符合12模式（Twelve-Factor App）：云原生应用架构的模式集合
-
微服务架构（Microservices）：独立部署的服务，一次只做一件事
-
自助服务敏捷基础设施（Self-Service Agile Infrastructure）：用于快速、可重复和一致地提供应用环境和服务的平台
-
面向API接口的通信（API-based Collaboration）：服务之间的交互基于接口，而不是本地方法调用
-
抗脆弱性（Anti-Fragility）：系统能抵御高负载
简单来说就是：
-
模块化（Modularity）
-
可观测性（Observability）
-
可部署性（Deployability）
-
可测试性（Testability）
-
可处理性（Disposability）
-
可替代性（Replaceability）
2019年，VMware Tanzu 官网给出了云原生最新定义，以及云原生的架构原则：
云原生是一种利用云计算交付模型的优势来构建和运行应用程序的方法论。当企业使用云原生架构开发和运维应用程序时，它们能更快速地响应客户需求将新想法推向市场。
虽然公共云影响了几乎所有行业对于基础设施的思维模式，但类似云的交付并不仅限于公共环境。云原生的开发同时适合公共云和私有云，你只需要关心应用程序是如何创建和部署，无需理会在哪部署。
更重要的是能够为开发人员提供按需访问计算能力以及现代数据和应用程序服务。云原生开发融合了 DevOps、连续交付、微服务和容器。
云原生架构原则：DevOps、Microservices、Containers、Security。
上面我提到云原生计算基金会（CNCF），是由开源基础设施界的翘楚 Google、RedHat 等公司共同牵头发起的一个基金会组织，其目的非常明确，就是为了对抗当时大红大紫的 Docker 公司在容器圈一家独大的局面。CNCF 通过 Kubernetes 项目在开源社区编排领域一骑绝尘，之后就扛起了云原生定义和推广的大旗，风光无限。
给大家看一眼CNCF的全景图吧！
2015 年 CNCF 把云原生定义为：应用容器化、面向微服务、容器编排。到了 2018 年，CNCF 更新了云原生的定义，加入了声明式 API 和服务网格（2017 年社区新技术，和微服务并列，注意它不是微服务的升级版本），这些技术能够构建容错性好，易于管理和便于观察的松耦合系统。2018年，大量科技公司开始接受云原生的概念，并纷纷加入到云原生的大家庭。此外，主流云计算供应商相继加入 CNCF，持续丰富整个云原生的生态。
4.1 IaaS（基础架构即服务）
IaaS（Infrastructure as a Service，基础架构即服务）是基础层。在这一层，通过虚拟化、动态化将IT基础资源（计算、网络、存储）聚合形成资源池。资源池即计算能力的集合，终端用户（企业）可以通过网络获得自己需要的计算资源，运行自己的业务系统。这种方式使用户不必自己建设这些基础设施，而是通过付费即可使用这些资源。
4.2 PaaS（平台即服务）
在IaaS层之上的是PaaS（Platform as a Service，平台即服务）层。这一层除了提供基础计算能力，还具备了业务的开发运行环境，提供包括应用代码、SDK、操作系统以及API在内的IT组件，供个人开发者和企业将相应功能模块嵌入软件或硬件，以提高开发效率。对于企业或终端用户而言，这一层的服务可以为业务创新提供快速、低成本的环境。
4.3 SaaS（软件即服务）
最上层是SaaS（Software as a Service，软件即服务）。实际上，SaaS在云计算概念出现之前就已经存在，并随着云计算技术的发展得到了更好的发展。SaaS的软件是“拿来即用”的，不需要用户安装，软件升级与维护也无须终端用户参与。同时，它还是按需使用的软件，与传统软件购买后就无法退货相较具有无可比拟的优势。
4.4 DaaS（数据即服务）
越来越多的数据沉淀、抽象形成了新的服务——DaaS（Data as a Service，数据即服务）。
数据聚合抽象，把数据转换成通用信息，从而为公众提供公共信息服务。例如，对于天气信息，可能A需要根据天气信息来判断出门穿着，B需要根据天气信息判断是否洗车，C需要根据天气信息判断是否准备防洪防涝设施等。不同用户均可利用DaaS满足自己的诉求。
此外，通过对各类数据信息进一步加工形成信息组合应用，会进一步盘活数据，提升数据价值。这就像搭积木一样，对基础数据信息块以不同的方式进行组装，可以达到千变万化的效果。DaaS服务已成为当下数字化转型的重要抓手。
5.1 云原生架构
容器化的出现，一定程度上带动了微服务架构。架构演化从单体式应用到分布式，再从分布式架构到云原生架构，微服务在其中有着不可或缺的角色。微服务带给我们很多开发和部署上的灵活性和技术多样性，但是也增加了服务调用的开销、分布式系事务、调试与服务治理方面的难题。
来看一看这个我早些年画的一个简易的架构图：
从上图Spring Cloud组件的架构可以看出在微服务架构中所必须的组件，包括：服务发现与注册、熔断机制、路由、全局锁、中心配置管理、控制总线、决策竞选、分布式会话和集群状态管理等基础组件。
Spring Cloud和Kubernetes有很大的不同，Spring Cloud和Kubernetes处理了不同范围的微服务架构技术点，而且是用了不同的方法。Spring Cloud方法是试图解决在JVM中的微服务架构要点，而Kubernetes方法是试图让问题消失，为开发者在平台层解决。Spring Cloud在JVM中非常强大，Kubernetes管理那些JVM很强大。看起来各取所长，充分利用这两者的优势是自然而然的趋势了。
5.2 DevOps
为了解决应用 “持续交付问题”，我们引入了 Devops。
提到交付问题，就想起大学的专业课——软件工程…这是个让人头疼的问题，我们知道，一个软件从零开始到最终交付，大概包括以下几个阶段：产品规划、开发编码、构建、QA测试、发布、部署和维护。
最初大家说到DevOps，都是指的‘开发运维一体化’，现在大家说的 DevOps 已经是扩大到“端到端”的概念了。
Devops 理念大家应该比较熟悉了，我理解它是一系列价值观，原则，方法，实践及工具的集合，目的是实现快速交付价值且具有持续改进能力，其核心是用于打破研发和运维之间的隔阂、加快软件交付流程、提高软件质量。
这里就不过多谈论了，给大家列出devops平台搭建工具
- 项目管理（PM）：jira。
运营可以上去提问题，可以看到各个问题的完整的工作流，待解决未解决等；
- 代码管理：gitlab。
jenkins或者K8S都可以集成gitlab，进行代码管理，上线，回滚等；
- 持续集成CI（Continuous Integration）：gitlab ci。
开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。
- 持续交付CD（Continuous Delivery）：gitlab cd。
完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境中。
-
镜像仓库：VMware Harbor，私服nexus。
-
容器：Docker。
-
编排：K8S。
-
服务治理：Nacos。
-
脚本语言：Python。
-
日志管理：Cat+Sentry，还有种常用的是ELK。
-
系统监控：Prometheus。
-
负载均衡：Nginx。
-
网关：Kong，SpringCloud Gateway。
-
链路追踪：SkyWalking。
-
产品和UI图：蓝湖。
-
公司内部文档：Confluence。
6.1 容器
容器雏形最早出现在 1979 年叫 Chroot Jail ，定义于 2008 年 即 LXC（Linux Container），将 Cgroups 的资源管理能力和 Namespace 的视图隔离能力组合在一起，实现进程级别的隔离。
然而容器最大的创新在于容器镜像（即集装箱，Docker “现象级” 开创），它包含了一个应用运行所需的完整环境（整个操作系统的文件系统），具有一致性、轻量级、可移植、语言无关等特性，实现 “一次发布，随处运行”（开发、测试、生产），使应用的构建、分发和交付完全标准化。
它也是 “不可变基础设施” 的核心基础。
6.2 Kubernetes
Kubernetes 是云计算和云原生时代的 Linux，是 Google 基于 Borg 开源的容器编排调度系统，让容器应用进入大规模工业生产。
声明式的 API 与可扩展（CRD + Controller）的编程接口，先进的设计思想使其在容器编排大战中（Kubernetes、Swarm、Mesos）处于王者地位，成为容器编排系统的事实标准。
通过采用 Kubernetes 平台，用户不必操心资源管理问题，使基础设施更加标准化，复杂度降低，资源使用率提升。同时 Kubernetes 也简化了混合云，多云，边缘云等跨数据中心的部署成本。
6.3 微服务(Microservices)
微服务则是一种用于构建应用的架构方案，微服务架构有别于为传统的单体应用的是将应用拆分成多个核心功能，每个功能都被称为一个独立的服务，可以单独构建和部署，其中某个服务出现故障也不会影响其他的功能模块，这句体现了其针对特定服务发布，影响小，风险小等特点。
6.4 无服务(Serverless)
根据 CNCF 的定义，Serverless 是指构建和运行不需要服务器管理的应用程序的概念。即开发人员无需关注底层的基础设施，只需要关注应用程序的业务本身就行，且该服务是可以自动扩展。
6.5 DevOps
早期的项目使用的是‘瀑布模型’进行软件交付，即一个阶段所有的完成工作之后再往下一个阶段，但这样的模式无法满足业务快速开发交付及变更需求的情况，于是后面就出现了敏捷开发这一概念，即一种快速应对需求变化软件开发能力，而DevOps就是基于敏捷开发将软件开发/测试人员/IT运维关联在一起，通过工具、组织等方式使开发、测试、发布流程自动化，软件发布频繁，高效。
6.6 ServiceMesh
ServiceMesh 核心是业务逻辑与非业务逻辑解耦，实现开发只需关注业务逻辑的伟大目标。将一大堆和业务逻辑无关的客户端 SDK（如服务发现，路由，负载均衡，限流降级等）从业务应用中剥离出来，放到单独的 Proxy（Sidecar） 进程中，之后下沉到基础设施中间件 Mesh（类似 TDDL 到 DRDS 的模式）。
针对应用减少了系统框架变更带来的风险、瘦身后变的干净和轻量化，加快了应用的启动速度，使得应用往 Serverless 架构迁移变得轻松。
针对 Mesh 可以根据自身需求自行迭代和升级功能，更加利于全局服务治理、灰度发布、监控等。
面试准备+复习分享：
为了应付面试也刷了很多的面试题与资料，现在就分享给有需要的读者朋友，资料我只截取出来一部分哦
务应用中剥离出来，放到单独的 Proxy（Sidecar） 进程中，之后下沉到基础设施中间件 Mesh（类似 TDDL 到 DRDS 的模式）。
针对应用减少了系统框架变更带来的风险、瘦身后变的干净和轻量化，加快了应用的启动速度，使得应用往 Serverless 架构迁移变得轻松。
针对 Mesh 可以根据自身需求自行迭代和升级功能，更加利于全局服务治理、灰度发布、监控等。
面试准备+复习分享：
为了应付面试也刷了很多的面试题与资料，现在就分享给有需要的读者朋友，资料我只截取出来一部分哦
[外链图片转存中…(img-RsZQuWko-1714696102969)]
389
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
