行业定制:什么是云原生？聊聊云原生和微服务的架构

　　行业定制:什么是云原生？聊聊云原生和微服务的架构

　　本次分享主要围绕以下4个主题展开：

　　什么是云原生？云计算和云原生

　　云计算不同于传统的自建机房。云计算将计算抽象为基础设施，并通过网络进行分发。得益于云计算的无限扩展能力，“云计算”就像一个水厂，我们可以随时连接。水，而且不限，根据自己家的用水量，可以交到自来水厂。以下是云计算的五个基本特征。

　　以下是一些比较主流的公有云厂商：

　　顾名思义，云原生是基于云计算特性设计的应用服务。得益于云计算的快速发展，基于云计算特性设计的云原生应用比传统的单一应用更加安全、可扩展、更快。运维等便利性具有巨大的领先优势。云原生不是指某种技术，它是一种架构设计理念。只要应用符合这种架构设计理念，就可以称为云原生应用。看看 CNCF 官方对云原生的定义：

　　容器云技术的发展

　　虚拟化技术的发展历程

　　云原生是依靠容器作为一种技术实现的，但容器并不是一种新潮的技术。以下是容器云技术的发展历程，包括几个关键的历史节点。

　　下图是CNCF全景图：

　　为什么要使用云原生架构？

　　主要从4个方面来谈：

　　自动恢复

　　早期刚开始工作时，我接管了一个年久失修的遗留系统。这个系统中的另一个惊人的错误会每天晚上自动关闭，没有人知道为什么。只要重新启动，就可以恢复正常。当时为了保证业务系统的正常使用，我总是半夜起来重启服务器。我在想：如果有一个工具可以检测到系统宕机，它会自动重启并恢复。所以我可以睡个好觉。

　　这是云原生架构要解决的第一个问题：应用系统挂掉后，可以在最短的时间内自动恢复，无需人工干预，保证系统的健壮性。

　　当然，除了未知的bug之外，还有一些奇怪的异常会导致服务崩溃，比如：

　　Kubernetes Pod 应用三种策略进行自动恢复：

　　spec:

restartPolicy: Always # 当容器终止退出后，总是重启容器，默认策略

containers:

- image: nginx

name: web

　　安全

　　在微服务架构的*敏*感*词*分布式系统中，通过熔断器在服务与服务之间建立安全保护隔离机制。

　　云原生架构的安全性保障系统主要有两个方面：

　　服务隔离

　　我们先来看看服务调用的安全隔离，如图：

　　如果服务A和服务B之间存在依赖调用关系，其处理逻辑如下：

　　如果服务 B 宕机或异常下线，注册中心会将服务 B 的状态发送给服务 A，服务 A 会启动断路器保护机制。，同时也保护了服务A的可用性。当服务B再次被拉起时，服务A从注册中心接收到服务B的健康检查，恢复对服务B的调用或者移除降级策略。

　　资源隔离

　　云原生架构对服务的保护机制还体现在资源的使用上。以往多系统共享一台主机的资源，总是容易出现木桶的短板效应，即只要一个系统占用了主机资源，那么其他系统就会因为资源不足而受到影响. 这会产生连锁反应，同一主机上的所有系统都会崩溃。

　　现在对于基于容器部署的微服务系统来说，你的系统在生产环境中的真正部署就像被关在一个小房间里一样。预先安排的资源设置是服务房间的大小，只能在指定的大小范围内。内部活动，即使程序内部异常导致所有资源被占用，也不会影响小伙伴在其他房间的正常活动，从而保证了整个系统的可用性

　　通过 Kubernetes 指定内存请求和限制的 Pod 配置文件：

　　spec:

containers:

- name: memory-demo-ctr

image: polinux/stress

<p>

resources:

limits:

memory: "200Mi" # 内存会被限制在 200 MiB 以内

requests:

memory: "100Mi" # 容器将会请求 100 MiB 内存

</p>

　　通过服务隔离和资源隔离，为云原生系统提供安全性和可用性。这里只是介绍介绍。如果你扩展它，还有更多的内容。有兴趣的同学可以自行学习探索。

　　弹性膨胀

　　传统的单体应用往往部署在机房的服务器主机中，自购服务器难以应对业务的快速增长，存在以下问题：

　　在基于云计算基本特性设计的云原生系统中，不存在上述问题。在主流公有云厂商中，ECS主机基本可以任意扩展配置，在资源使用上也提供了按量付费的运营模式。，有效避免计算资源的限制和浪费。如下：

　　快速释放

　　随着 Kubernetes 等云原生基础设施的改进，现代应用程序的部署方式也与以前大不相同。与传统低效的宕机发布相比，云原生服务提供的滚动更新帮助我们实现了不宕机升级系统的目标。对于需要快速响应市场需求的企业来说，快速迭代业务系统的功能让企业获得市场竞争力显得尤为重要。

　　KubernetesRollingUpdate策略用于解决不停发布的问题：

　　另外，我们可以通过 kubectl rollout undo 将部署回滚到指定版本，解决微服务快速回滚的问题。

　　以上就是云原生架构相比传统系统带来的巨大优势。我们目前处于云时代架构演进的早期阶段。我个人认为，作为知识工作者的我们程序员非常值得花时间学习下一代主流架构设计。这将为我们带来巨大的技术优势和技术领先地位。

　　微服务的概念微服务的理论基础

　　微服务并不特指特定的技术，它是一个抽象的概念。只要满足其所有规范，就可以理解为为您的系统实现了微服务。

　　什么时候使用微服务？

　　关于您的项目何时应该引入微服务架构，业界有两种声音：

　　其实早在2015年，科技巨头Martin Fowler就在文章MicroservicePremium的博客中给出了参考答案：

　　早期（2015年左右），使用微服务的成本和入门门槛都很高，生产效率不如单体应用。但随着系统业务复杂度的逐渐增加，单体应用的生产效率逐渐降低。当达到临界点时，微服务的优势逐渐显现，微服务的生产效率开始超过单体应用。

　　因此，2015年，结合成本和收益的平衡，大多数人会选择单一优先的架构方案，然后逐渐向微服务演进。

　　Netflix OSS 的诞生

　　早在 2015 年，CNCF 基金会刚刚诞生，社区的微服务基础设施非常不完善。Netflix+Pivotal作为微服务实践的探索者，在应用层面提供了很多微服务的基础组件来实现微服务架构。关于Netflix提供的名为Netflix OSS（开源软件中心）的微服务全家桶解决方案

　　关于组件的详细介绍，我在《了解基于Netflix OSS的微服务架构》一文中也有介绍，这里不再赘述。

　　Netflix OSS全景图如下：

　　微服务优先

　　Martin Fowler 在 2015 年提出的观点显然已经不再适用于 2021 年的现代系统架构。随着 CNCF 近年来的快速发展，云原生基础设施逐渐完善和成熟，使用微服务的成本已经逐年减少。服务的实现成本已经趋向于单体，未来甚至会比单体更好。我个人的看法是，如果微服务能够解决使用和学习成本的问题，那么未来微服务将完全取代单体应用。从长远来看，任何新项目都应该优先考虑微服务架构，这样既可以保证业务系统的生产效率和可扩展性，又可以避免未来*敏*感*词*重构。

　　微服务技术选型 微服务框架选型

　　市场上有许多微服务框架。目前业内大公司基本都有自己的微服务框架。我们只看几个主流且具有代表性的微服务框架：

　　我们根据自己的理解比较函数看看如何实现微服务的基本理论概念

　　我们从微服务的基本侧重点、运维架构、产品背景三个维度对比主流框架：

　　通过横向对比，我们可以看到 Dubbo 和 Spring Cloud 相比 Kubernetes 都有很多不足。与阿里巴巴的 Dubbo 和 Netflix 的 Spring Cloud 相比，谷歌提供的 Kubernetes 是具有完整的一站式微服务解决方案的技术解决方案。如图所示：

　　如果用房屋来类比，前者就像毛坯房，必须自己装修，而 Kubernetes 是精装修的商品房，可以帮你解决所有问题，拎着包就可以安顿下来. 另外，自建Kubernetes集群成本比较高，推荐使用公有云厂商提供的Kubernetes服务。

　　微服务和网关

　　如果把分布式微服务系统比作一家公司，那么网关就是公司的前台。当用户想要访问公司时，他必须在前台登记并确认他的身份。疫情期间，他可能还需要量体温什么的。此步骤称为网关身份验证。根据用户描述的任务和用户携带的证书，网关用户的服务类型将用户带到业务范围内的办公室。此步骤称为网关路由。如果一个前台处理不了的用户太多，就会多开几个窗口来分流。此步骤称为网关级别的负载平衡。网关是微服务的大门，对微服务至关重要。

　　以下是网关通常的工作方式：

　　除了上述的认证、动态路由、负载均衡之外，还可以通过网关实现以下高级功能：

　　

　　网关是微服务的大门，因为网关对微服务至关重要，是微服务弹性伸缩能力的源泉。而且网关的开发成本其实并不高，所以市面上有很多单独的网关产品，我们可以简单的看一下，如图：

　　微服务和安全认证

　　早期分布式单体应用程序的会话管理

　　在早期的单应用用户会话解决方案中，服务器存储 sessionid + cookid + filter 来保存和管理用户状态会话。但是这种有状态服务有很多弊端，比如服务重启后用户状态丢失、水平扩展困难等。在后单体应用时代，大家开始把用户会话状态放到Redis等存储中间件中来解决系统水平扩展和重启后会话丢失的问题。

　　结构如图所示：

　　微服务中基于 Auth 的认证方案

　　在微服务系统中，身份认证模块会被统一提取出来，交给一个单独的服务进行处理，通常称为Auth Service。访问令牌通常由 Auth 颁发，并由网关统一认证。AuthService 身份验证职责的分离，让微服务更专注于业务。

　　基于Auth Service的工作逻辑如图：

　　但是，这种基于 Auth 认证服务的方案会将所有请求都发送给 Auth 进行验证。鉴权服务压力大，架构方案繁重，造成不必要的性能损失。事实上，大多数应用系统并不需要如此严格的安全认证级别。那么有没有一种轻量级的技术，可以不依赖Auth认证，由认证服务下发，服务可以自己验证token的有效性，可以大大减少对Auth的认证请求。答案是肯定的。它是目前非常流行的 JWT 认证方案。

　　JWT 结合 RBAC 角色权限模型是目前非常主流的轻量级认证方案。其工作流程如下：

　　JWT之所以备受推崇和广泛使用，是因为在Auth服务下发token后，可以在网关处验证token的合法性，无需再请求认证服务，请求更少，效果更好表现。令牌本身也可以收录少量的用户信息。JWT 大概就是一串这样的代码。它由三部分组成。您可以通过 JWT IO 网站 对 JWT 进行解码，以获取 JWT 中的信息：

　　JWT的详细生成和解码过程这里不再赘述。JWT 并非没有缺点。我们来看看它的优缺点：

　　优势劣势

　　小巧轻便

　　一经发出，不可撤销，只能自动过期

　　减轻 Auth 压力，简化 Auth 实现

　　收录的信息越多，传输开销越大

　　总结

　　RBAC角色模型+JWT认证方案是目前微服务主流的安全认证体系，也能满足大部分系统对安全认证的需求。这也是市场上大多数企业应用程序生产的最佳实践。

　　微服务运维监控

　　生产就绪系统

　　说完开发过程，再来说说微服务是如何运维的。我们知道仅仅完成功能（Feature-Complete）只是软件开发过程中很小的一部分，那么从编码到生产准备需要经过哪些步骤呢？我们可以参考下图：

　　当我们确保应用程序已准备好生产时，我们可以将其发布到生产环境并交付价值

　　基于EFK的日志采集方案

　　基于容器部署的微服务架构无法像传统应用一样通过SSH登录服务器抓取日志信息，只能采用统一的采集机制。

　　在 Kubernetes 中推荐使用 EFK (Elasticsearch + Fluentd + Kibana) 采集 日志。其工作流程如下：

　　Fluentd会将采集的日志直接发送到ElasticSearch，中间也可以加kafka作为缓存层 ElasticSearch 最初通过Log Parser解析日志，可以过滤垃圾日志 通过Kibana Dashboard查询ElasticSearch显示日志

　　分布式系统服务监控方案

　　目前主流的微服务监控系统是通过Kubernetes+Prometheus搭建的，如图：

　　通过 Prometheus Monitor 发现 Kubernetes 服务，并通过 Alert Manager 告警 Email，通过 Grafana 通过 SMS 显示和监控服务运行指标

　　基于Skywalking的分布式链路跟踪监控

　　Skywalking是一个非侵入式分布式链路跟踪框架，无需添加一行代码即可完成微服务分布式系统的链路跟踪。是目前主流的分布式链路跟踪解决方案。In 2019, SkyWalking became Apache The top-level project, the author of SkyWalking, Wu Sheng, was also elected as the first Chinese director of the Apache Software Foundation. 我不会在这里详细介绍。SkyWalking的一般工作原理如下：

　　SkyWalking 的分布式调用链演示：

　　总结

　　本文从云原生的发展史出发，讲述了为什么我们的程序员应该拥抱和选择云原生。阐述了基于云计算的基础衍生出来的云原生系统对传统单体应用带来的颠覆性变化，然后描述了部分微服务的工作原理、架构布局和运维方案。但在一个真正的生产级云原生应用中，远不止以上，还有更多的因素需要考虑，比如：

　　不再赘述，期待与大家学习交流，谢谢。

　　参考：

　　本文是使用知乎在 VSCode 上撰写和发布的

　　整体解决方案:度盛智能建站系统

　　都胜智能建站系统适用于地方教育局、集团和大型企事业单位。可实现直属单位或直属单位统一管理，模板编辑灵活，支持PC/移动端“零码”快速建站，快速文章编辑，文章分享，专业信息采集、问卷、自定义表格……无需代码，建站更简单，管理更方便

　　平台功能介绍：

　　平台包括首页、我的站点、频道管理、内容管理、用户管理、通知管理、飘窗管理、公共频道、统计管理、问卷管理、敏感词管理等11个功能模块。

　　首页：显示为待办事项、流量统计和快捷操作内容，可以引导用户选择模板-修改页面-发布文章-解析域名-发布上线；

　　

　　我的站点：核心功能之一，分为我的站点和域名管理。我的站点可以管理站点名称、记录号、标题、关键词、图片、描述等信息。域名管理可以统一管理平台的域名；

　　频道管理：可以统一管理网站频道；

　　内容管理：分为8个模块：文章管理、待审核、我的文章、分享文章、存档文章、回收站、图片管理、音频管理. 模块可以统一管理平台发布的所有文章；

　　用户管理：该模块用于对平台用户进行统一管理。包括基本用户信息和角色权限信息等；

　　公告管理：该模块可以发布平台公告，关键信息可以及时同步；

　　

　　凸窗管理：该模块可以对平台凸窗进行统一管理；

　　公共频道：该模块可以统一管理站群中默认的导航频道；

　　统计管理：该模块分为六个模块：得分统计、来源统计、访问详情、分区统计、浏览器统计、屏幕统计。可以对站点进行各种统计查看和管理；

　　问卷管理：该模块可以对问卷进行管理，可以对问卷进行添加、删除、编辑等操作；

　　敏感词管理：该模块可以对发布的文章中的敏感词进行管理，防止收录敏感词的文章被发布到网站。