之前写过一篇关于微服务架构的文章，觉得很火，所以今天打算聊一聊云原生和微服务架构。图片来自宝途网本文主要围绕以下四个主题展开：什么是云原生？为什么要使用云原生架构？微服务的概念微服务技术选型什么是云原生？①云计算与云原生云计算不同于传统的自建机房。云计算是将计算抽象为基础设施，然后通过网络进行分发。得益于云计算的无限扩展性，“云计算”就像一座水厂。我们随时可以接水，没有限制。根据自家用水量，我们可以向自来水厂缴费。以下是云计算的五个基本特征：下面是一些比较主流的公有云厂商：云原生，顾名思义，就是基于云计算的特征而设计的应用服务。与传统单体应用相比，云原生应用在安全性、可扩展性、快速迭代、运维便捷性等方面具有巨大优势。云原生并不是指某种技术，它是一种架构设计理念，只要应用符合这种架构设计理念，就可以称为云原生应用。看看CNCF官方对云原生的定义：②容器云技术的发展虚拟化技术的发展历程云原生是依托容器技术实现的，但容器并不是新潮技术。以下是容器云技术的发展史，有几个关键的历史节点：早在2006年，亚马逊基于容器技术的IaaS平台AWS成为所有云计算厂商的鼻祖。由于其技术领先地位，AWS仍然是云计算行业的领头羊。2013年Docker的诞生进一步简化了容器技术的使用。Docker自认为掌握了云时代的核心技术，开始雄心勃勃地挑战传统的云计算巨头，如RedHat和谷歌。绝尘，却败给了RedHat和Google联合发布的Kubernetes。Kubernetes的成功让大家认为容器技术不是云时代的核心技术，容器编排才是核心技术。（注：2020年，K8S官方宣布只要满足K8SCRI接口的容器都可以被K8S编排，Docker被时代抛弃。）2015年，随着Kubernetes的成功，谷歌宣布成立CNCF基金会，是云原生时代的代表。组织。致力于完善云时代的基础设施，帮助开发者打造更好的产品。下图是CNCF全景：为什么要用云原生架构？下面从四个方面说一下：服务的自动恢复安全和弹性扩展快速发布①自动恢复初期，我刚开始工作的时候，接手了一个年久失修的遗留系统。这个系统有一个很神奇的bug，每天晚上都会自动关机，不知道为什么。只要重新启动，就会恢复正常。当时，为了保证业务系统的正常使用，我总是半夜起床重启服务器。我当时就在想：如果有一个工具可以检测到系统宕机，它会自动重启恢复。是的，所以我可以睡个好觉。这是云原生架构要解决的第一个问题：应用系统挂掉后，能够在最短时间内自动恢复，无需人工干预，保证系统的健壮性。当然，除了未知的bug，还有一些奇怪的异常会导致服务崩溃，例如：代码没有写好，服务器自身资源不足导致系统OOM，死锁，磁盘，网络以及其他问题等等……KubernetesPod应用自动恢复三种策略：Always：当容器终止退出时，始终重启容器，默认策略。OnFailure：当容器异常退出时（退出状态码不为0），会重启容器。从不：当容器终止并退出时，永远不会重新启动容器。spec:restartPolicy:Always#当容器终止退出时，始终重启容器。默认的策略容器：-image:nginxname:web②安全性在微服务架构的大规模分布式系统中，服务之间的安全性是通过熔断保护隔离机制来建立的。云原生架构保障体系的安全性主要体现在两个方面：服务隔离资源隔离服务隔离：我们先来看服务调用的安全隔离，如图：如果服务A和服务A之间存在依赖调用关系服务B，其处理逻辑如下：如果服务B宕机或异常下线，注册中心会将服务B的状态发送给服务A，服务A启动熔断保护机制。服务A采取降级策略或者不再向服务B发送请求，避免调用链雪崩，保护服务A的可用性。当服务B再次拉起时，服务A收到注册中心对服务B的健康检查，恢复调用服务B或删除降级策略。资源隔离：云原生架构对服务的保护机制也体现在资源的使用上。以往，多个系统共享一台主机的资源，总是容易出现木桶的短板效应。即只要一个系统占满主机资源，其他系统就会因资源不足而受到影响。反过来，会发生连锁反应，同一台主机上的所有系统都会崩溃。现在基于容器化的微服务系统，你的系统真正部署到生产环境就像被锁在一个小房间里，预先安排好的资源设置就是服务房间的大小。它只能在指定的尺寸范围内移动。即使内部程序异常导致所有资源被占用，也不会影响其他房间小伙伴的正常活动，从而保证了整个系统的可用性。通过Kubernetes指定内存请求和限制的Pod配置文件：spec:containers:-name:memory-demo-ctrimage:polinux/stressresources:limits:memory:"200Mi"#Memory将被限制为200MiBrequests:memory:"100Mi"#容器会通过服务隔离申请100MiB内存。资源隔离为云原生系统提供安全性和可用性。这里只是介绍一下。去研究和探索。③传统单体应用的弹性扩展往往部署在机房的服务器主机中，自购服务器难以应对业务的快速增长，存在以下问题：时间成本：购买服务器需要填写提前做好配置清单，走完各种流程，等物流，等机器发货上电，估计1~2周过去了。空间成本：你必须为这些大家伙腾出很多空间。其他成本：24小时空调、专人轮班值班、机器维护、服务下线后服务器容易闲置、闲鱼难卖等。在基于云计算的基本特性，不存在这些问题。主流公有云厂商提供的ECS主机基本可以任意扩展配置，资源使用也提供了按量付费的运行模式，有效避免了计算资源的局限和浪费。如下图所示：④快速发布随着Kubernetes等云原生基础设置的完善，现代应用的部署方式也与以往有了很大的不同。相比于传统低效的宕机发布，云原生服务提供的RollingUpdate帮助我们实现了系统不停机升级的目标。对于需要快速响应市场需求的企业来说，快速迭代业务系统必不可少的功能对于企业获得市场竞争力就显得尤为重要。KubernetesRollingUpdate策略用于解决不间断发布的问题：另外我们可以通过kubectlrolloutundo将部署回滚到指定版本，解决微服务快速回滚的问题。以上就是云原生架构相较于传统系统所带来的巨大优势。我们目前正处于云时代架构演进的早期阶段。我个人认为，作为知识工作者，我们程序员是值得投入时间去学习下一代主流架构设计的。这将为我们带来巨大的技术优势和技术领先地位。微服务的概念①微服务的理论基础微服务并不是指具体的技术，它是一个抽象的概念，只要满足它的所有规范，就可以理解为你的系统实现了微服务。②什么时候使用微服务？关于你的项目什么时候引入微服务架构，业界一直有两种声音：方案A单体优先：随着架构的演进逐渐被微服务架构取代方案B微服务优先：避免后期大规模的架构重构其实早as2015年，技术大师MartinFowler在博文MicroservicePremium中给出了参考答案：早期（2015年左右），使用微服务的成本和上手门槛高，生产效率不如作为整体应用程序很好。但随着系统业务复杂度逐渐增加，单体应用的生产效率逐渐降低。当达到临界点时，微服务的优势逐渐显现，微服务的生产效率开始超过单体应用。因此，在2015年，考虑到成本和收益的权衡，大部分人会选择单体优先的架构方案，然后逐步向微服务演进。③NetflixOSS早在2015年CNCF基金会诞生时就诞生了，社区中的微服务基础设施非常不完善。Netflix+Pivotal作为微服务实践中的探索者，在应用层提供了很多微服务的基础组件来实现微服务架构。Netflix提供的微服务全家桶解决方案叫做NetflixOSS（OpenSourceSoftwareCenter）。NetflixOSS全景图如下：④微服务优先级MartinFowler在2015年的观点显然不再适用于2021年的现代系统架构。近年来，随着CNCF的快速发展，云原生基础设施逐渐完善和完善。日趋成熟，使用微服务的成本逐年降低。实施微服务的成本已经趋于与单体应用相近，未来甚至会优于单体应用。我个人的看法是，如果微服务能够解决使用和学习成本的问题，那么未来微服务将完全取代单体应用。从长远来看，任何新项目都应该优先考虑微服务架构，这样既能保证业务系统的生产力和可扩展性，又能避免日后大规模重构。微服务技术选型①微服务框架选型市面上的微服务框架有很多。目前业内大公司基本上都有自己的微服务框架。我们只看几个主流的、有代表性的微服务框架：Dubbo（阿里巴巴）SpringCloud（Netflix）Kubernetes（谷歌）下面我们通过功能对比，看看如何根据自己的理解来实现微服务的基本理论概念。我们从微服务的基本关注点、运维架构、产品背景三个维度来对比主流框架：通过横向对比，我们可以看出Dubbo和SpringCloud与Kubernetes相比都有很多不足之处。与阿里巴巴的Dubbo、Netflix的SpringCloud相比，谷歌的Kubernetes是一个完整的一站式微服务解决方案的技术方案。如下图：如果用住房来比喻的话，前者就像是毛坯房，需要自己装修，而Kubernetes是精装修的商品房，可以帮你解决所有问题，而且你可以搬进你的包。另外，自建Kubernetes集群成本较高，推荐使用公有云厂商提供的Kubernetes服务。②微服务和网关如果把分布式微服务系统比作一个公司，那么网关就是公司的前台。当用户想要访问公司时，他必须在前台登记并确认他的身份。疫情期间，他可能需要测量体温什么的。此步骤称为网关身份验证。根据用户描述的任务和身上携带的证明，网关用户的业务类型将把用户带到业务范围内的办公室。此步骤称为网关路由。如果用户太多，一个前台搞不定，就多开几个窗口分流。此步骤称为网关级别的负载平衡。网关是微服务的大门，对微服务至关重要。以下是网关的常用工作方式：除了上述的认证、动态路由、负载均衡，还可以通过网关实现以下高级特性：网关限流（人多关门，或者在门口排队）金丝雀发布（把小部分用户带到还没有开放的新办公空间去体验）弹性伸缩网关是微服务的大门，因为网关对微服务来说非常重要，是微服务弹性伸缩能力的源泉。而网关的开发成本其实并不高，所以市场上有很多单独的网关产品，我们可以简单的看一下，如图：③早期分布式单体应用的微服务和安全认证会话管理：早期单体applicationUsersessionschemes通过在server端存储sessionid+cookid+filter来存储和管理用户态session。但是这种有状态的服务有很多缺点，比如服务重启后用户状态丢失，水平扩展困难等。在后单体应用时代，人们开始将用户会话状态放在Redis等存储中间件中解决系统横向扩展以及重启后session不丢失的问题。架构如图：微服务中基于Auth的认证方案：在微服务体系中，身份认证模块会被统一抽取出来，交给单独的服务处理，通常称为AuthService。访问令牌通常由Auth颁发，由网关统一认证。AuthService身份认证职责分离，让微服务更加关注业务。基于AuthService的工作逻辑如图所示：但是，这种基于Auth认证服务的方案会将所有请求发送给Auth进行验证。认证服务压力大，架构方案重，造成不必要的性能损失。事实上，大多数应用系统并不需要如此严格的安全认证级别。那么有没有一种轻量级的技术，可以让认证服务不依赖于Auth认证而签发token，服务可以自己验证token的合法性，这样可以大大减少对Auth的认证请求。答案是肯定的。是目前非常流行的JWT认证方案。JWT结合RBAC角色权限模型是目前非常主流的轻量级认证方案。它的工作流程如下：JWT之所以备受推崇和广泛使用，是因为它可以在Auth服务颁发令牌后在网关验证令牌的合法性，而无需再次请求身份验证服务，请求更少，性能更好。令牌本身也可以包含少量用户信息。JWT大概就是这样的一串代码。它由三部分组成。可以通过JWTIO网站对JWT进行解码，获取JWT中的信息：JWT的详细介绍生成和解码过程这里不再赘述。JWT并非没有缺点。来看看它的优缺点：总结：RBAC角色模型+JWT认证方案是目前主流的微服务安全认证体系，也可以应对大部分系统。对安全认证的要求也是目前市面上大部分企业应用在生产中的最佳实践。④微服务运维监控生产就绪系统ProductionReady：说完开发过程，再说说微服务是如何运维的。我们知道仅仅完成功能（Feature-Complete）只是软件开发过程的一小部分，那么从完成编码到生产就绪（ProductionReady）需要经过哪些环节呢？我们可以参考上图：集成测试：用户功能准确度、性能和压力测试。日志管理：日志要标准化，区分不同级别：Info、Wrong、Error等。日志格式统一，便于日志收集、监控和故障排除。监控预警：包括业务指标监控、应用指标监控、CPU、内存、磁盘网络IO监控等，设置合理的预警信息。调用链监控：展示分布式系统的调用关系，调用性能，发现性能瓶颈，快速定位问题。高可用的考虑：双机备份、主从备份、异地多活、容灾策略、应用弹性机制等。当我们确保应用满足生产就绪（ProductionReady）要求时，我们就可以发布它生产和交付价值。基于EFK的日志采集方案：基于容器部署的微服务架构无法像传统应用一样通过SSH登录服务器采集日志信息，只能采用统一的采集机制。推荐使用EFK（Elasticsearch+Fluentd+Kibana）在Kubernetes中收集日志。其工作流程如上图所示：Fluentd会将采集到的日志直接发送给ElasticSearch，中间也可以加入Kafka作为缓存层。ElasticSearch最初通过LogParser来解析日志，它可以过滤垃圾日志。通过KibanaDashboard查询ElasticSearch显示日志。分布式系统的服务监控方案：目前主流的微服务监控系统是通过Kubernetes+Prometheus搭建的。如上图所示：通过PrometheusMonitor发现Kubernetes服务，通过AlertManager报警Email，通过GrafanaSMS显示监控服务运行情况基于Skywalking分布式链路跟踪监控的各种指标：Skywalking是一个非侵入式的分布式链路跟踪框架，可以用于在不添加一行代码的情况下完成微服务分布式系统的链接跟踪，是目前主流的分布式链接跟踪方案。In2019,SkyWalkingbecamethetopApacheproject,andtheauthorofSkyWalking,WuSheng,wasalsoelectedasthefirstChinesedirectoroftheApacheSoftwareFoundation,soIwon’ttalkaboutithere.SkyWalking的大致工作原理如下：SkyWalking的分布式调用链展示：本文总结了云原生的发展历史，阐述了我们的程序员为什么拥抱和选择云原生。阐述了从云计算的基础上衍生出的云原生系统对传统单体应用带来的颠覆性变化，进而阐述了部分微服务的工作原理、架构布局和运维方案。但在真正的生产级云原生应用中，需要考虑的因素远不止上述这些。例如：HTTPS编码规范、测试覆盖率、E2E测试监控：Log/Trace/Metrics、业务指标监控持续集成：CI/CD流水线完整的README帮助文档不再赘述，期待学习和工作与大家交流，谢谢大家。作者：小斌2编辑：陶佳龙来源：转载自公众号小二十七（ID：drak-phoenix）
