Serverless技术
Serverless的模式
回顾软件技术发展的历史，我们会发现“抽象、分解、集成、复用”的主题贯穿始终，行业的每一次更新换代都伴随着更高程度的软件服务模式的抽象，并随之引起IT行业的商业模式革新。
● On-Premises（本地部署）：硬件裸机时代，机房所有的硬件、操作系统、容器、运行时环境、应用、函数等都需要自己管理。
● IaaS（基础设施即服务）：IaaS处于底层，服务商提供底层或物理层的基础设施资源（如数据中心、电源、服务器机房），客户自己部署应用程序等各种软件。
● CaaS（容器即服务）：CaaS服务的出现使我们不再需要自己维护操作系统层面的东西，只需要维护业务应用系统即可。
● PaaS（平台即服务）：PaaS处于中间层，服务商提供基础设施的底层服务、操作系统，客户自己控制上层的应用程序部署。
● FaaS（函数即服务）：FaaS提供一个平台，用户实现业务函数逻辑，无须构建、维护与开发和启动应用程序相关的基础架构。
Serverless的提出
Serverless可以理解为由开发者实现的服务端逻辑运行在无状态的计算容器中，它由事件触发，完全被第三方管理。Serverless架构可以帮助我们减少部署、提高扩展性，并减轻代码后面的基础设施的维护负担。
Serverless从广义上包含FaaS和BaaS（后端即服务）两方面。
FaaS解决了应用本身的“无服务器”化，BaaS解决了应用依赖的第三方服务的“无服务器”化。当应用和其依赖的服务都实现了“无服务器”化时，这个应用才算是完整的Serverless应用。
Serverless模型使客户仅需要关心“业务代码”，设计好自己的业务模型，把代码部署到云服务中，就可以完成一系列复杂的部署、运维、监控操作。
Serverless的技术前景
Serverless的使用场景
● Serverless 适 用 于 应 用 后 端 事 件 触 发 场 景 ， 通 过 调 用Serverless云函数，实现文件上传、简单的消息推送、定时器任务等功能。
● Serverless适用于应用的AI智能对话场景，Serverless最核心的竞争优势不仅仅是云函数，更重要的是服务商本身所提供的AI能力。
● Serverless提供云端安全认证服务，可以减少不必要的IT重复建设。
● Serverless提供大数据处理能力，最典型的就是物联网应用，解决实时海量大数据计算和存储问题。
Knative的Serverless架构方案
Knative是谷歌开源的一套Serverless架构方案。它提高了构建可在本地、云和第三方数据中心等地方运行的现代化的、以资源为中心且基于容器的应用的能力，以Kubernetes的CRD形式运行存在。
Knative专注于解决以容器为核心的Serverless应用的构建、部署和运行的问题，构建在Kubernetes和Istio的基础上，为构建和部署Serverless及基于事件驱动的应用程序提供了一致的标准模式。
Knative的目标是提供标准的Serverless编排框架，简化烦琐的构建、部署、应用运维、服务治理等步骤，逐渐成为主流的无服务平台和技术的标准。
总结
在前面的章节中，我们已经讨论了很多与微服务有关的话题，最后让我们快速回顾总结一下全书的核心内容。
技术与价值
从早期的SOA架构开始，微服务以一种区别于传统单体应用的细粒度服务实现方式出现，使用分布式架构技术解决软件面临的系统性问题，逐渐成为企业开发的主流架构模式。作为一种“基础架构”技术，微服务融合了云原生12因子、领域驱动设计、Docker、SpringBoot、Spring Cloud框架、康威定律、DevOps、CI/CD等众多架构理念和软件技术开发实践。
微服务作为一种优化资源组织的体系结构方法，其价值在于解决实际系统面临的复杂性问题。随着业务规模的扩大，单体应用的程序变得无法适应和管理，微服务架构通过把整体应用划分为小型、自治、独立的服务集群，来有效地提升整体业务系统的可管控性、可维护性、可扩展性。从软件工程的角度来看，微服务通过代码层面的解耦，有利于团队的并行化开发，提高应用系统的交付效率，缩短生产周期；微服务也让开发人员从庞大的单体架构中解脱，不必理解整体系统工程，只需要关注自己负责的业务模块；微服务之间可以通过定义轻量化、标准、规范、用户友好的API进行集成交互。
同时，微服务可以有效地分离业务与技术的复杂度，通过将重复的组件沉淀在微服务架构底座，结合基础设施的隔离运行机制及持续集成、持续交付工具，将与业务无关的共性技术问题抽离，这样开发人员可以专注于业务本身。相比单体架构，微服务在快速响应、弹性、容错、维持速度、可演性方面都有更加显而易见的优势。
然而，微服务不是“银弹”，将整体系统分解为微服务后带来的系统分散性问题，以及微服务对技术、人员、组织、流程管理带来的研发习惯、工作模式的改变，都是考验企业转型微服务架构的重要决策因素。总而言之，任何技术的采用都需要结合业务实际情况进行一番利弊权衡。正所谓“最合适的技术才是最有价值的技术”。如果你的应用只是短期、小众用户的项目，完全可以不考虑系统架构；而随着时间推移，当用户量增长、业务新增需求，而你的系统无法扩展，需要重构扩展时，技术架构对业务的价值影响和冲击可能会造成无法挽回的损失。
业务与平台
微服务的实践围绕业务和平台两个方向发展，二者不存在割裂的关系，在开发实践的优先级方面，应该根据公司的发展战略和业务发展阶段有不同的侧重。
大部分企业都基于业务驱动方式选择微服务，原因是随着业务发展到一定程度，积累了大量的单体应用，需要依靠微服务的拆分和领域分解，解决日益增长的业务复杂性问题。微服务在这个阶段主要围绕业务进行微服务化改造。以Spring Boot为代表的基底模式是业务转型微服务的主要构建模式，以DDD（领域驱动设计）思想为指导，结合业务逻辑、开发人员技术能力、组织结构、基础IT架构等多方面因素综合考虑落地实践微服务。
在微服务的治理平台建设方面，随着服务规模的扩大，以SpringCloud为代表的技术生态为规模化服务提供注册中心、配置中心、微服务网关、容错管理、集成交互、服务链路监控、日志聚集管理等基础设施和能力。
对于微服务的运行时平台，容器目前仍然是微服务应用运行的最佳虚拟环境和载体。容器技术虽然本质上与微服务是独立的，并且有着不同的解决领域和目标，然而结合DevOps实践方法论，它们共同组成了云原生架构的底层技术平台。伴随着微服务规模的增长、发布和交付的频率加快，缺少了容器技术的支持，将使微服务的规模化发展难以维系。自动化CI/CD和以Kubernetes技术为代表的PaaS平台建设成为微服务自动化、规模化、平台化阶段的主要工作。
本文给大家讲解的内容是微服务发展趋势，Serverless技术
- 觉得文章不错的朋友可以转发此文关注小编；
- 感谢大家的支持！
本文就是愿天堂没有BUG给大家分享的内容，大家有收获的话可以分享下，想学习更多的话可以到微信公众号里找我，我等你哦。
