前端专题技术总结

1 端到端
端到端流程是从客户需求端出发，到满足客户需求端去，提供端到端服务，端到端的输入端是市场，输出端也是市场。这个端到端必须非常快捷，非常有效，中间没有水库，没有三峡，流程很顺畅。如果达到这么快速的服务，降低了人工成本，降低了财务成本，降低了管理成本，也就是降低了运作成本。其实，端到端的改革就是进行内部最简单的最科学的管理体系的改革，形成一支最精简的队伍。
端到端的流程连起来的不只是两个紧邻部门，而是若干部门，是某个业务的全程闭环（businesscycle）。这个端到端的流程，从分析客户需求开始，到收集客户反馈结束，中间经历了概念形成、市场研究、应用开发、产品实现、市场测试、销售推广、业绩评估等几个阶段，涉及营销部、研发部、采购部、生产部等若干部门。而且，这个端到端的流程实际上包含了诸如营销流程、采购流程等局部流程。
国内流程管理水平比较高的企业都已开展端到端的流程，如华为的集成产品开发（IPD）流程、集成供应链（ISC）流程，上海贝尔—阿尔卡特的“from order tocash”流程，这些流程都不同于企业部门内部或者紧邻部门之间的细节流程 [1] 。
端到端流程的重要性
通过一个小的实际案例给大家说明端到端管理流程的必要性和重要性：
某公司的人力资源部门接二连三地接到员工的投诉：奖金的发放不及时。但人力资源部门的主管感到非常委屈，他觉得奖金发放流程本身没有问题，而且平时也是严格按照奖金发放流程来执行，他们不应该承担责任而且也无法独立解决这个问题。但问题又出现在哪里呢？经分析，奖金发放不及时的原因主要有两个：一是每月奖金核算数据给到人力资源部门的日期不确定，经常有延误现象；二是奖金发放后因为业绩核算规则的频繁变化调整导致个人数据不正确时，来回反复确认工作非常耗时。而负责奖金核算流程的核算部门也很委屈，因为他们认为人力资源部并没有对核算的时效做出一个明确的规定，而且数据发给人力资源部后，如果数据存在问题往往不能及时反馈到核算部。
这个案例很好地揭示了端到端管理流程的必要性和重要性。从客户需求（员工要求奖金及时且准确）来看，满足这一共同需求的并非奖金发放流程，而且还有奖金核算流程。所以，单纯地强调奖金发放流程是不够的。如果想完整地满足和解决客户的需求，必须把两个子流程组合成一个大的端到端流程来分析解决。只有从开始核算数据到奖金下发到员工账户看成一个完整的端到端流程，才能有效地解决此问题。虽然两个流程单个分析都不错，但一旦整合起来分析，就会发现很多工作根本没必要分成两段串行完成，整合后的流程很多工作都可以并行处理，这样就能大大提高处理时效。最后，公司把奖金核算流程和奖金发放流程整合成了一个奖金核算及发放流程，这样就能整合重新设计工作线路并在关键的环节设立时效考核指标，方案实施后，效果立竿见影！HR并对整合后的流程整体负责。
串行🡪并行
2 P2P、区块链技术
一种网络新技术，依赖网络中参与者的计算能力和带宽，而不是把依赖都聚集在较少的几台服务器上
纯点对点网络没有客户端或服务器的概念，只有平等的同级节点，同时对网络上的其它节点充当客户端和服务器。这种网络设计模型不同于客户端-服务器模型，在客户端-服务器模型中通信通常来往于一个中央服务器。
纯P2P
节点同时作为客户端和服务器端。
没有中心服务器。
没有中心路由器。
杂P2P
有一个中心服务器保存节点的信息并对请求这些信息的要求做出响应。
节点负责发布这些信息（因为中心服务器并不保存文件），让中心服务器知道它们想共享什么文件，让需要它的节点下载其可共享的资源。
路由终端使用地址，通过被一组索引引用来取得绝对地址。
混合P2P
同时含有纯P2P和杂P2P的特点。
P2P网络的一个重要的目标就是让所有的客户端都能提供资源，包括带宽，存储空间和计算能力。因此，当有节点加入且对系统请求增多，整个系统的容量也增大。这是具有一组固定服务器的C/S结构不能实现的，这种结构中客户端的增加意味着所有用户更慢的数据传输。
P2P网络的分布特性通过在多节点上复制数据，也增加了防故障的健壮性，并且在纯P2P网络中，节点不需要依靠一个中心索引服务器来发现数据。在后一种情况下，系统也不会出现单点崩溃。
点对点技术有许多应用。共享包含各种格式音频，视频，数据等的文件是非常普遍的，实时数据（如IP电话通信、Anychat音视频）也可以使用P2P技术来传送。
有些网络和通信渠道，像Napster，OpenNAP，和IRC @find,一方面使用了C/S结构来处理一些任务（如搜索功能），另一方面又同时使用P2P结构来处理其他任务。而有些网络，如Gnutella和 Free*** ，使用P2P结构来处理所有的任务，有时被认为是真正的P2P网络。尽管Gnutella 也使用了目录服务器来方便节点得到其它节点的网络地址。
区块链：
从本质上讲，它是一个共享数据库，存储于其中的数据或信息，具有“不可伪造”“全程留痕”“可以追溯”“公开透明”“集体维护”等特征。基于这些特征，区块链技术奠定了坚实的“信任”基础，创造了可靠的“合作”机制，具有广阔的运用前景。
区块链是一个分布式的共享账本和数据库，具有去中心化、不可篡改、全程留痕、可以追溯、集体维护、公开透明等特点。这些特点保证了区块链的“诚实”与“透明”，为区块链创造信任奠定基础。而区块链丰富的应用场景，基本上都基于区块链能够解决信息不对称问题，实现多个主体之间的协作信任与一致行动
区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式
在区块链系统中，没有任何一个机构或个人可以实现对全局数据的控制，而任一节点停止工作都不会影响系统整体运作，这种去中心化的网络将极大地提升数据安全性。
其次区块链的优势体现在数据不可篡改性：区块链利用加密技术来验证与存储数据、利用分布式共识算法来新增和更新数据，区块链需要各节点参与验证交易和出块；修改任一数据需要变更所有后续记录，修改单节点数据难度极大。在传统信息系统的安全方案中，安全依赖于层层设防的访问控制。通过区块链技术，记录交易的数据库任何人都可以访问，但由于巧妙的设计并辅以密码学和共识机制，区块链的数据记录方式使得修改某一数据需要变更所有的后续数据记录，难度极大。一旦信息经过验证并添加至区块链，就会永久的存储起来，除非能够同时控制住系统中超过51%的节点，否则单个节点上对数据库的修改是无效的，因此区块链的数据稳定性和可靠性极高。
不仅如此，区块链的优势还体现数据安全可靠与可溯源性：写入的区块内容将备份复制到各节点中，各节点都拥有最新的完整数据库拷贝且所有的记录信息都是公开的，任何人通过公开的接口都可查询区块数据。区块链中的每一笔交易通过链式存储固化到区块数据中，同时通过密码学算法对所有区块的所有交易记录进行叠加式 HASH 摘要处理，因此可追溯到任何一笔交易历史。
最后区块链的优势体现在集体维护性：区块链去中心化的特征决定了它的集体维护性。传统中心化机构通常要身兼三职：数据存储者、数据管理者和数据分析者，区块链则以对等的方式由各参与方共同维护，各方权责明确，无需向第三方机构让渡权利，实现共同协作。
3 中台
由于强调“打通”，中台项目往往意味者要跟所有部门梳理业务，所以耗费人力特别多，而人力成本是导致“中台”项目花钱最凶的部分。在此之前还有一个更基础的问题：中台究竟是什么？

几乎很难在业界得到一条关于中台的恒定解释，但有一条关键标准：是否能够复用。
　起初，阿里只有一个淘宝事业部，后来成立了天猫事业部，此时淘宝的技术团队同时支撑着这两个事业部。当时的淘宝和天猫的电商系统像我们很多大型企业的一样是分为两套独立的烟囱式体系，两套体系中都包含的有商品、交易、支付、评价、物流等功能。因为上述原因，阿里集团又成立了共享业务事业部，其成员主要来自之前的淘宝技术团队，同时将两套电商业务做了梳理和沉淀，将两个平台中公共的、通用的业务功能沉淀到共享事业部，避免重复建设和维护。
 　　“大中台、小前台”架构主要集中在业务共享服务层，业务共享服务团队，有独立的团队来做，也更利于业务的沉淀，降低研发成本，提高研发效率。打破了产品壁垒，之前是系统之间要数据，现在是都去找共享服务中心要数据，共享服务中心提供统一的，标准的数据。减少了系统间交互、团队间协作的成本。站在巨人的肩膀上。新产品研发不用考虑之前已有的东西，可以快速孵化新的产品，试错成本低，产品敢于创新，敢于拥抱变化，原来追竞争对手都很困难，现在相当于竞争对手的产品经理不停的给我们提供新点子。可持续发展，技术和业务能力能够沉淀积累。
为什么要微服务化？
　　在传统单体或SOA架构下，应用如果频繁升级更新，开发团队非常痛苦。企业的业务应用经过多年IT建设，系统非常庞大，要改动其中任何一小部分，都需要重新部署整个应用，敏捷开发和快速交付无从谈起。　传统企业在长期的IT建设过程中，通常大量使用外包团队，这导致采用的技术栈之间差异较大，统一管控和运维要求更高。需要运维7*24小时全天候值守、在线升级，并快速响应。在此时脱颖而出的微服务技术，面对上述困惑几乎浑身优点：独立开发、独立部署、独立发布，去中心化管理，支持高并发高可用，支持丰富技术栈，企业可以根据需要灵活技术选型。
微服务是将企业通用服务按业务化分成一个个单体服务，增强可用性、服务易扩展、减少开发成本、减少服务发布对整个平台的影响。微服务是一种思想，实现有很多方式，企业转由单个系统转向微服务就要考虑很多问题，比如技术选型、业务拆分问题、高可用、服务通信、服务发现和治理、集群容错、配置管理、数据一致性问题、康威定律、分布式调用跟踪、CI/CD、微服务测试，以及调度和部署等等，这并非一些简单招数能够化解。

　　微服务框架必须能够达到借助虚拟化平台，能够按需创建机器并调整大小，借助基础设施的自动化从一台机器扩展到多台，拥有业务监控预警、异常熔断等等功能，现有框架有Dubbo和SpringCloud，Dubbo是RPC服务治理框架，和SpringCloud一样具备服务注册、发现、路由、负载均衡等能力。















4 SOA架构和微服务架构的区别
5 SOA架构和微服务架构的区别
5.1 SOA架构特点：
系统集成：站在系统的角度，解决企业系统间的通信问 题，把原先散乱、无规划的系统间的网状结构，梳理成 规整、可治理的系统间星形结构，这一步往往需要引入 一些产品，比如 ESB、以及技术规范、服务管理规范； 这一步解决的核心问题是【有序】

系统的服务化：站在功能的角度，把业务逻辑抽象成 可复用、可组装的服务，通过服务的编排实现业务的 快速再生，目的：把原先固有的业务功能转变为通用 的业务服务，实现业务逻辑的快速复用；这一步解决 的核心问题是【复用】

业务的服务化：站在企业的角度，把企业职能抽象成 可复用、可组装的服务；把原先职能化的企业架构转变为服务化的企业架构，进一步提升企业的对外服务能力；“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。第三步，则是以业务驱动把一个业务单元封装成一项服务。这一步解决的核心问题是【高效】
3.微服务架构特点：
1.通过服务实现组件化

开发者不再需要协调其它服务部署对本服务的影响。
2.按业务能力来划分服务和开发团队

开发者可以自由选择开发技术，提供 API 服务
3.去中心化

每个微服务有自己私有的数据库持久化业务数据
每个微服务只能访问自己的数据库，而不能访问其它服务的数据库
某些业务场景下，需要在一个事务中更新多个数据库。这种情况也不能直接访问其它微服务的数据库，而是通过对于微服务进行操作。
数据的去中心化，进一步降低了微服务之间的耦合度，不同服务可以采用不同的数据库技术（SQL、NoSQL等）。在复杂的业务场景下，如果包含多个微服务，通常在客户端或者中间层（网关）处理。
4.基础设施自动化（devops、自动化部署）

的Java EE部署架构，通过展现层打包WARs，业务层划分到JARs最后部署为EAR一个大包，而微服务则打开了这个黑盒子，把应用拆分成为一个一个的单个服务，应用Docker技术，不依赖任何服务器和数据模型，是一个全栈应用，可以通过自动化方式独立部署，每个服务运行在自己的进程中，通过轻量的通讯机制联系，经常是基于HTTP资源API，这些服务基于业务能力构建，能实现集中化管理（因为服务太多啦，不集中管理就无法DevOps啦）。







SOA粗暴理解：把系统按照实际业务，拆分成刚刚好大小的、合适的、独立部署的模块，每个模块之间相互独立。比如现我有一个数据库，一个JavaWeb（或者PHP等）的网站客户端，一个安卓app客户端，一个IOS客户端。现在我要从这个数据库中获取注册用户列表，如果不用SOA的设计思想，那么就会这样：JavaWeb里面写一个查询方法从数据库里面查数据然后在网页显示，安卓app里面写一个查询方法查询后在app上显示，IOS同样如此。这里就会出现查询方法重叠了，这样的坏处很明显了，三个地方都有相同的业务代码，要改三个地方都要改，而且要改的一模一样。当然问题不止这一个。
于是乎出现了这样的设计思想，比如用Java（或者是其他语言皆可）单独创建一个工程部署在一台服务器上，并且写一个方法（或称函数）执行上述查询操作，然后使其他人可以通过某种途径（可以是http链接，或者是基于socket的RPC调用）访问这个方法得到返回数据，返回的数据类型是通用的json或者xml数据，就是说把这个操作封装到一个工程中去，然后暴露访问的方式，形成“服务”。比如这里就是注册用户服务，而关于注册用户的所有相关增删改查操作这个服务都会提供方法。这样一来，JavaWeb这边可以访问这个服务然后得到数据使用，安卓和IOS这里也可以通过这个服务得到数据。而且最重要的是，要修改关于注册用户的业务方法只要改这个服务就好了，很好的解耦。同理，其他业务比如商品、广告等业务都可以单独形成服务部署在单独服务器上。还有就是一旦哪天突然有一堆人要注册，假设这堆人仅仅只是注册而不做其他事情，其他业务比如商品、广告服务等都不忙，唯独注册这个功能压力很大，而原有的一台部署了注册服务的服务器已经承受不了这么高的并发，这时候就可以单独集群部署这个注册服务，提供多几台服务器提供注册服务，而其他服务还不忙，那就维持原样。当然，还有很多其他好处。
以上我所描述的都还不能完全称为SOA，还不够完整，因为它少了服务治理这一环节。什么是服务治理，就是当服务越来越多，调用方也越来越多的时候，它们之间的关系就变得非常混乱，需要对这些关系进行管理。举例，还是上面的例子，假如我有一个用户服务，一开始有调用方1和调用方2来使用这个服务，后来越来越多，将近上百个调用方，这个时候作为服务方，它只知道提供服务，却不知道具体为谁提供了服务。而对于开发者来说，知道这N多调用方和N多服务方之间的关系是非常重要的。所以这个时候就需要能进行服务治理的框架，比如dubbo+zookeeper，比如SpringCloud，有了服务治理功能，我们就能清晰地看到服务被谁谁谁调用，谁谁谁调用了哪些服务，哪些服务是热点服务需要配置服务器集群，而对这个服务集群的负载均衡也是服务治理可以完成的重要功能之一。
这个时候就是更加完善一点的SOA了。当然，还可以更进一步，加上服务监控跟踪等等等等之类的。实际上SOA只是一种架构设计模式，而SOAP、REST、RPC就是根据这种设计模式构建出来的规范，其中SOAP通俗理解就是http+xml的形式，REST就是http+json的形式，RPC是基于socket的形式。上文提到的CXF就是典型的SOAP/REST框架，dubbo就是典型的RPC框架，而SpringCloud就是遵守REST规范的生态系统。




微服务顾名思义，就是很小的服务，所以它属于面向服务架构的一种。通俗一点来说，微服务类似于古代著名的发明，活字印刷术，每个服务都是一个组件，通过编排组合的方式来使用，从而真正做到了独立、解耦、组件化、易维护、可复用、可替换、高可用、最终达到提高交付质量、缩短交付周期的效果。

从专业的角度来看，微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 协议的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

所以总结起来，微服务的核心特点为：小, 且专注于做⼀件事情、轻量级的通信机制、松耦合、独立部署。

1.微服务的优势

微服务之所以能盛行，必然是有它独特优势的，下面我们来分析微服务有哪些方面的优势。

（1）技术异构性

在微服务架构中，每个服务都是一个相对独立的个体，每个服务都可以选择适合于自身的技术来实现。如，要开发一个社交平台，此时，我们可能使用文档型数据库来存储帖 子的内容，使用图数据来存储朋友圈的这些关系等，这样可以把每一块的性能都充分发挥 出来。

同时，在应用新技术时，微服务架构也提供了更好的试验场。因为对于单块的系统而 言，采用一个新的语言、数据库或者框架都会对整个系统产生巨大的影响，这样导致我们 想尝试新技术时，望而却步。但微服务不同，我们完全可以只在一个微服务中采用新技术， 待技术使用熟练之后，再推广到其他服务。

（2）弹性

弹性主要讲的是系统中一部分出现故障会引起多大问题。在单块系统中，一个部分出现问题，可能导致整体系统的问题。而微服务架构中，每个服务可以内置可用性的解决方 案与功能降级方案，所以比单块系统强。

（3）扩展

单块系统中，我们要做扩展，往往是整体进行扩展。而在微服务架构中，可以针对单个服务进行扩展。

（4）简化部署

在大型单块系统中，即使修改一行代码，也需要重新部署整个应用系统。这种部署的影响很大、风险很高，因此不敢轻易地重新部署。而微服务架构中，每个服务的部署都是 独立的，这样就可以更快地对特定部分的代码进行部署。

（5）与结织结构相匹配

我们都知道，团队越大越难管理，同时团队越大也代表系统规模越大代码库越大，这样容易引起一系列的问题。且当团队是分布式的时候，问题更严重。微服务架构就能很好地解决这个问题，微服务架构可以将架构与组织结构相匹配，避免出现过大的代码库，从而获得理想的团队大小及生产力。服务的所有权也可以在团队之 间迁移，从而避免异地团队的出现。

（6）可组合性

在微服务架构中，系统会开放很多接口供外部使用。当情况发生改变时，可以使用不同的方式构建应用，而整体化应用程序只能提供一个非常粗粒度的接口供外部使用。

（7）对可替代性的优化

在单块系统中如果删除系统中的上百行代码，也许不知道会发生什么，引起什么样的问题，因为单块系统中关联性很强。但在微服务架构中，我们可以在需要时轻易地重写服务，或者删除不再使用的服务。

2. 微服务面临的挑战

软件开发业内有一句名言“软件开发没有银弹”，虽然前面介绍了微服务很多方面的优势，但微服务并不能解决所有问题。下面我们来分析在使用微服务架构时可能面临的一些挑战。

（1）分布式系统的复杂度

使用微服务实现分布式系统的复杂度要比单块系统高。这表现在多个方面，如：性能方面微服务是拆分成多个服务进行部署，服务间的通信都是通过网络，此时的性能会受影响。同时可靠性也会受影响。数据一致性也需要严格控制，其成本也比单块系统高。

（2）运维成本

相比传统的单块架构应用，微服务将系统分成多个独立的部分，每个部分都是可以独立部署的业务单元。这就意味着，原来适用于单块架构的集中式的部署、配置、监控或者日志收集等方式，在微服务架构下，随着服务数量的增多，每个服务都需要独立的配置、部署、监控、日志收集等，因此成本呈指数级增长。

（3）部署自动化

传统单块系统部署往往是以月、周为单位，部署频度很低，在这种情况下，手动部署是可以满足需求的。而对于微服务架构而言，每个服务都是一个独立可部署的业务单元，每个服务的修改都需要独立部署。这样部署的成本是比较高的，如亚马逊，每天都要执行数十次、甚至上百次的部署，此时仍用人工部署是行不通的，要使用自动化部署。如何有效地构建自动化部署流水线，降低部署成本、提高部署频率，是微服务架构下需要面临的一个挑战。

（4）DevOps 与组织结构

传统单块架构中，团队通常是按技能划分，如开发部、测试部、运维部，并通过项目的方式协作，完成系统交付。而在微服务架构的实施过程中，除了如上所述的交付、运维上存在的挑战，在组织或者团队层面，如何传递 DevOps 文化的价值，让团队理解 DevOps 文化的价值，并构建全功能团队，也是一个不小的挑战。

微服务不仅表现出一种架构模型，同样也表现出一种组织模型。这种新型的组织模型意味着开发人员和运维的角色发生了变化，开发者将承担起服务整个生命周期的责任，包括部署和监控，而运维也越来越多地表现出一种顾问式的角色，尽早考虑服务如何部署。因此，如何在微服务的实施中，按需调整组织架构，构建全功能的团队，是一个不小的挑战。

（5）服务间依赖测试

由于微服务架构是把系统拆分为若干个可独立部署的服务，所以需要进行服务间的依赖测试。在服务数量较多的情况下，如何有效地保证服务之间能有效按照接口的约定正常工作，成为微服务实施过程中必须面临的巨大挑战。

（6）服务间依赖管理

传统的单块系统，功能实现比较集中，大部分功能都运行在同一个应用中，同其他系统依赖较少。而微服务架构则不同，在将系统功能拆分成相互协作的独立服务之后，随着微服务个数的增多，如何清晰有效地展示服务之间的依赖关系，成为了一个挑战。





单体应用架构和微服务架构
一、单体应用架构概念
一个归档包（可以是JAR、WAR、EAR或其它归档格式）包含所有功能的应用程序，通常称为单体应用。 而架构单体应用的方法论，就是单体应用架构。
二、单体架构示意图

三、单体应用架构的优缺点
1. 优点
●便于共享：单个归档文件包含所有功能，便于在团队之间以及不同的部署阶段之间共享。
●易于测试：单体应用一旦部署，所有的服务或特性就都可以使用了，这简化了测试过程，因为没有额外的依赖，每项测试都可以在部署完成后立刻开始。
●易于部署：只需将单个归档文件复制到单个目录下。
2. 缺点
●复杂性高：由于是单个归档文件，所以整个项目文件包含的模块非常多，导致模块的边界模糊、依赖关系不清晰、代码的质量参差不齐，混乱的堆在一起，使得整个项目非常复杂。以致每次修改代码，都非常小心，可能添加一个简单的功能，或者修改一个Bug都会带来隐藏的缺陷。
●技术债务：随着时间的推移、需求的变更和技术人员的更替，会逐渐形成应用程序的技术债务，并且越积越多。
●扩展能力受限：单体应用只能作为一个整体进行扩展，无法根据业务模块的需要进行伸缩。
●阻碍技术创新：对于单体应用来说，技术是在开发之前经过慎重评估后选定的，每个团队成员都必须使用相同的开发语言、持久化存储及消息系统。
四、微服务架构概念
微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。
五、微服务架构示意图

六、微服务架构的优缺点
1. 优点
●易于开发和维护：一个微服务只会关注一个特定的业务功能，所以业务清晰、代码量较少。开发和维护单个微服务相对简单。
●单个微服务启动较快
●局部修改容易部署：单体应用只要有修改，就得重新部署整个应用。微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可。
●技术栈不受限制：在微服务架构中，可以结合项目业务及团队的特点，合理的选择技术栈。
●按需伸缩：可根据需求，实现细粒度的扩展。
2. 缺点
●运维要求高：更多的服务意味着要投入更多的运维。
●分布式固有的复杂性：使用微服务构建的是分布式系统。对于一个分布式系统，系统容错、网络延迟、分布式事务等都会带来巨大的问题。
●接口调整成本高：微服务之间通过接口进行通信。如果修改某一个微服务的API，可能所有用到这个接口的微服务都需要进行调整。




6 Serverless 能取代微服务吗
Serverless 是一个更大的范畴，Serverless 不只计算，也包括存储、数据库、中间件等各种服务。Serverless = FaaS（函数即服务） + BaaS（后端即服务）。其中 Serverless 计算一般指 FaaS，即云函数。云函数和微服务不是取代关系。微服务是一种架构模式，而云函数是实现微服务的一种方式。微服务可以用云函数实现，也可以用 K8S + 容器，或者 VM 实现。判断选择用什么来实现微服务，要从可靠性、成本、性能、工程效率、安全性等维度出发。不同的场景有不同的取舍。当前的 Serverless 计算服务还有很多限制，而阿里云函数计算2.0解决了这些痛点，目标是提供在可靠性、成本、性能、工程效率上最具竞争力的计算服务。所以我们的目标不是取代微服务，而是成为支撑微服务最好的平台。

所谓的云函数，你可以认为，它实际上就是将我们传统的代码，拆分成了更细的粒度，部署在云上，拆分成函数粒度又部署在云上，就是所谓的云函数，而这些函数又可以提供某种服务，所以可以认为Function as a service。

先说一下云函数的特点。云函数既然是传统业务演变而来，那么一定有他的优势，否则不会无辜的进行演变。传统业务，我们在开发上线的过程中，需要团队合作，每个人开发一部分，合并代码，开发联调，然后进行资源评估，测试环境搭建、线上环境搭建、测试上线、运维。但是在云函数的时代下，或者说是Serverless的时代下，我们开发者，只需要开发自己那部分功能/函数，然后部署到测试环境、线上环境就可以了。至于所谓的资源评估、后期的很大一部分运维工作，都是可以避免或者不去考虑和担心。这么看来，Serverless架构的出现，是为了提高安全性、稳定性，提升开发效率、降低成本，这样看来，Serverless架构上运行主要业务貌似就没有什么问题了，毕竟可以把这个过程看作是时代发展过程。

接下来从细节和实例进行分析，我也是一个个人开发者，我有一个在线编程的软件，目前下载量已经突破75万，之前我这个软件的后台服务是放在云主机上，云主机是一个4核8G的主，加1个2核4G的节，同时做了大量的业务逻辑，来对两台机器的CPU使用率和内存使用率进行判断和监控，一旦超过某个阈值，就要进行新的主机的创建和配置，以及加入集群，夜间的时候，流量可能比较低，可能一台2核4G的就足够了，有的时候流量比较高，他可能会开出来1-2个节点进行工作，这个算是我在运维层面费尽心机做的一个策略，虽然相对稳定，靠谱，思路也算是抄袭K8S HPA API V2，但是实际上，他的整个扩缩容过程，赖于监控频率以及机器加入的速率，如果并发出现瞬间的提高，可能还是会影响一部分用户的使用的。后来接触到了云函数，我将我很多的业务逻辑，放在了云函数上面，事实证明，扩缩容，弹性伸缩这样传统需要我们自身需要考虑的问题，完全可以交给云厂商来做，我们要做的就是写最核心的业务逻辑。什么是最核心的业务逻辑？


1. 无服务器（Serverless）计算是什么
云计算涌现出很多改变传统IT架构和运维方式的新技术，比如虚拟机、容器、微服务，无论这些技术应用在哪些场景，降低成本、提升效率是云服务永恒的主题。
过去十年来，我们已经把应用和环境中很多通用的部分变成了服务。Serverless的出现，带来了跨越式变革。Serverless把主机管理、操作系统管理、资源分配、扩容，甚至是应用逻辑的全部组件都外包出去，把它们看作某种形式的商品——厂商提供服务，我们掏钱购买。
过去是“构建一个框架运行在一台服务器上，对多个事件进行响应”，Serverless则变为“构建或使用一个微服务或微功能来响应一个事件”，做到当访问时，调入相关资源开始运行，运行完成后，卸载所有开销，真正做到按需按次计费。这是云计算向纵深发展的一种自然而然的过程。
Serverless是一种构建和管理基于微服务架构的完整流程，允许你在服务部署级别而不是服务器部署级别来管理你的应用部署。它与传统架构的不同之处在于，完全由第三方管理，由事件触发，存在于无状态（Stateless）、暂存（可能只存在于一次调用的过程中）计算容器内。构建无服务器应用程序意味着开发者可以专注在产品代码上，而无须管理和操作云端或本地的服务器或运行时。Serverless真正做到了部署应用无需涉及基础设施的建设，自动构建、部署和启动服务。
国内外的各大云厂商 Amazon、微软、Google、IBM、阿里云、腾讯云、华为云相继推出Serverless产品，Serverless也从概念、愿景逐步走向落地，在各企业、公司应用开来。
2. 理解Serverless技术—FaaS和BaaS
Serverless由开发者实现的服务端逻辑运行在无状态的计算容器中，它由事件触发， 完全被第三方管理，其业务层面的状态则被开发者使用的数据库和存储资源所记录。Serverless涵盖了很多技术，分为两类：FaaS和BaaS。
2.1 FaaS（Function as a Service，函数即服务）
FaaS意在无须自行管理服务器系统或自己的服务器应用程序，即可直接运行后端代码。其中所指的服务器应用程序，是该技术与容器和PaaS（平台即服务）等其他现代化架构最大的差异。
FaaS可以取代一些服务处理服务器（可能是物理计算机，但绝对需要运行某种应用程序），这样不仅不需要自行供应服务器，也不需要全时运行应用程序。
FaaS产品不要求必须使用特定框架或库进行开发。在语言和环境方面，FaaS函数就是常规的应用程序。例如AWS Lambda的函数可以通过Javascript、Python以及任何JVM语言（Java、Clojure、Scala）等实现。然而Lambda函数也可以执行任何捆绑有所需部署构件的进程，因此可以使用任何语言，只要能编译为Unix进程即可。FaaS函数在架构方面确实存在一定的局限，尤其是在状态和执行时间方面。
在迁往FaaS的过程中，唯一需要修改的代码是“主方法/启动”代码，其中可能需要删除顶级消息处理程序的相关代码（“消息监听器接口”的实现），但这可能只需要更改方法签名即可。在FaaS的世界中，代码的其余所有部分（例如向数据库执行写入的代码）无须任何变化。
相比传统系统，部署方法会有较大变化 – 将代码上传至FaaS供应商，其他事情均可由供应商完成。目前这种方式通常意味着需要上传代码的全新定义（例如上传zip或JAR文件），随后调用一个专有API发起更新过程。
FaaS中的函数可以通过供应商定义的事件类型触发。对于亚马逊AWS，此类触发事件可以包括S3（文件）更新、时间（计划任务），以及加入消息总线的消息（例如Kinesis）。通常你的函数需要通过参数指定自己需要绑定到的事件源。
大部分供应商还允许函数作为对传入Http请求的响应来触发，通常这类请求来自某种该类型的API网关（例如AWS API网关、Webtask）。
2.2 BaaS（Backend as a Service，后端即服务）
BaaS（Backend as a Service，后端即服务）是指我们不再编写或管理所有服务端组件，可以使用领域通用的远程组件（而不是进程内的库）来提供服务。理解BaaS，需要搞清楚它与PaaS的区别。
首先BaaS并非PaaS，它们的区别在于：PaaS需要参与应用的生命周期管理，BaaS则仅仅提供应用依赖的第三方服务。典型的PaaS平台需要提供手段让开发者部署和配置应用，例如自动将应用部署到Tomcat容器中，并管理应用的生命周期。BaaS不包含这些内容，BaaS只以API的方式提供应用依赖的后端服务，例如数据库和对象存储。BaaS可以是公共云服务商提供的，也可以是第三方厂商提供的。其次从功能上讲，BaaS可以看作PaaS的一个子集，即提供第三方依赖组件的部分。
BaaS服务还允许我们依赖其他人已经实现的应用逻辑。对于这点，认证就是一个很好的例子。很多应用都要自己编写实现注册、登录、密码管理等逻辑的代码，而对于不同的应用这些代码往往大同小异。完全可以把这些重复性的工作提取出来，再做成外部服务，而这正是Auth0和Amazon Cognito等产品的目标。它们能实现全面的认证和用户管理，开发团队再也不用自己编写或者管理实现这些功能的代码。
3. 无服务器（Serverless）计算如何工作？
与使用虚拟机或一些底层的技术来部署和管理应用程序相比，无服务器计算提供了一种更高级别的抽象。因为它们有不同的抽象和“触发器”的集合。
拿计算来讲，这种抽象有一个特定函数和抽象的触发器，它通常是一个事件。以数据库为例，这种抽象也许是一个表，而触发器相当于表的查询或搜索，或者通过在表中做一些事情而生成的事件。
比如一款手机游戏，允许用户在不同的平台上为全球顶级玩家使用高分数表。当请求此信息时，请求从应用程序到API接口。API接口或许会触发AWS的Lambda函数，或者无服务器函数，这些函数再从数据库表中获取到数据流，返回包含前五名分数的一定格式的数据。
一旦构建完成，应用程序的功能就可以在基于移动和基于 Web 的游戏版本中重用。
这跟设置服务器不同，不是必须要有Amazon EC2实例或服务器，然后等待请求。环境由事件触发，而响应事件所需的逻辑只在响应时执行。这意味着，运行函数的资源只有在函数运行时被创建，产生一种非常高效的方法来构建应用程序。
4. 无服务器（Serverless）适用于哪些场景？
在现阶段，Serverless主要应用在以下几个场景。首先在Web及移动端服务中，可以整合API网关和Serverles服务构建Web及移动后端，帮助开发者构建可弹性扩展、高可用的移动或 Web后端应用服务。在IoT场景下可高效的处理实时流数据，由设备产生海量的实时信息流数据，通过Serverles服务分类处理并写入后端处理。另外在实时媒体资讯内容处理场景里，用户上传的音视频到对象存储OBS，通过上传事件触发多个函数，分别完成高清转码、音频转码等功能，满足用户对实时性和并发能力的高要求。无服务器计算还适合于任何事件驱动的各种不同的用例，这包括物联网，移动应用，基于网络的应用程序和聊天机器人等。这里简单说两个场景，方便大家思考。
4.1 场景一：应用负载有显著的波峰波谷
Serverless 应用成功与否的评判标准并不是公司规模的大小，而是其业务背后的具体技术问题，比如业务波峰波谷明显，如何实现削峰填谷。一个公司的业务负载具有波峰波谷时，机器资源要按照峰值需求预估；而在波谷时期机器利用率则明显下降，因为不能进行资源复用而导致浪费。
业界普遍共识是，当自有机器的利用率小于 30%，使用 Serverless 后会有显著的效率提升。对于云服务厂商，在具备了足够多的用户之后，各种波峰波谷叠加后平稳化，聚合之后资源复用性更高。比如，外卖企业负载高峰是在用餐时期，安防行业的负载高峰则是夜间，这是受各个企业业务定位所限的；而对于一个成熟的云服务厂商，如果其平台足够大，用户足够多，是不应该有明显的波峰波谷现象的。
4.2 场景二：典型用例 - 基于事件的数据处理
视频处理的后端系统，常见功能需求如下：视频转码、抽取数据、人脸识别等，这些均为通用计算任务，可由函数计算执行。
开发者需要自己写出实现逻辑，再将任务按照控制流连接起来，每个任务的具体执行由云厂商来负责。如此，开发变得更便捷，并且构建的系统天然高可用、实时弹性伸缩，用户不需要关心机器层面问题。
5. Serverless 的问题
对于企业来说，支持Serverless计算的平台可以节省大量时间和成本，同时可以释放员工，让开发者得以开展更有价值的工作，而不是管理基础设施。另一方面可以提高敏捷度，更快速地推出新应用和新服务，进而提高客户满意度。但是Serverless不是完美的，它也存在一些问题，需要慎重应用在生产环境。
5.1 不适合长时间运行应用
Serverless 在请求到来时才运行。这意味着，当应用不运行的时候就会进入 “休眠状态”，下次当请求来临时，应用将会需要一个启动时间，即冷启动时间。如果你的应用需要一直长期不间断的运行、处理大量的请求，那么你可能就不适合采用 Serverless 架构。如果你通过 CRON 的方式或者 CloudWatch 来定期唤醒应用，又会比较消耗资源。这就需要我们对它做优化，如果频繁调用，这个资源将会常驻内存，第一次冷启之后，就可以一直服务，直到一段时间内没有新的调用请求进来，则会转入“休眠”状态，甚至被回收，从而不消耗任何资源。
5.2 完全依赖于第三方服务
当你所在的企业云环境已经有大量的基础设施的时候，Serverless 对于你来说，并不是一个好东西。当我们采用某云服务厂商的 Serverless 架构时，我们就和该服务供应商绑定了，那么我们再将服务迁到别的云服务商上就没有那么容易了。
我们需要修改一下系列的底层代码，能采取的应对方案，便是建立隔离层。这意味着，在设计应用的时候，就需要隔离 API 网关、隔离数据库层，考虑到市面上还没有成熟的 ORM 工具，让你既支持Firebase，又支持 DynamoDB等等。这些也将带给我们一些额外的成本，可能带来的问题会比解决的问题多。
5.3 缺乏调试和开发工具
当我使用 Serverless Framework 的时候，遇到了这样的问题：缺乏调试和开发工具。后来，我发现了 serverless-offline、dynamodb-local 等一系列插件之后，问题有一些改善。然而，对于日志系统来说，这仍然是一个艰巨的挑战。
每次你调试的时候，你需要一遍又一遍地上传代码。而每次上传的时候，你就好像是在部署服务器，并不能总是快速地定位出问题在哪。后来，找了一个类似于 log4j 这样的可以分级别记录日志的 Node.js 库 winston。它可以支持 error、warn、info、verbose、debug、silly 六个不同级别的日志，再结合大数据进行日志分析过滤，才能快速定位问题。
5.4 构建复杂
Serverless 很便宜，但是这并不意味着它很简单。AWS Lambda的 CloudFormation配置是如此的复杂，并且难以阅读及编写（JSON 格式），虽然CloudFomation提供了Template模板，但想要使用它的话，需要创建一个Stack，在Stack中指定你要使用的Template,然后aws才会按照Template中的定义来创建及初始化资源。
而Serverless Framework的配置更加简单，采用的是 YAML 格式。在部署的时候，Serverless Framework 会根据我们的配置生成 CloudFormation 配置。然而这也并非是一个真正用于生产的配置,真实的应用场景远远比这复杂。
6. 总结
云计算经过这么多年的发展，逐渐进化到用户仅需关注业务和所需的资源。比如，通过K8S这类编排工具，用户只要关注自己的计算和需要的资源（CPU、内存等）就行了，不需要操心到机器这一层。
Serverless架构让人们不再操心运行所需的资源，只需关注自己的业务逻辑，并且为实际消耗的资源付费。可以说，随着Serverless架构的兴起，真正的云计算时代才算到来了。
任何新概念新技术的落地，本质上都是要和具体业务去结合，去真正解决具体问题。虽然Serverless很多地方不成熟，亟待完善。不过Serverless自身的优越特性，对于开发者来说，吸引力是巨大的。相信随着技术的飞速发展，Serverless在未来还有无限可能！

7 serverless

基于 Node.js 的前端工程化
2009年 Node.js 的出现，对于前端来说，也是一个历史性的时刻。随着 Node.js 一同出现的还有 ***monJS 规范和 npm 包管理机制。随后也出现了 Grunt、Gulp、Webpack 等一系列基于 Node.js 的前端开发构建工具。
在 2013 年前后，前端三大框架 React.js/Angular/Vue.js 相继发布第一个版本。我们可以从以往基于一个个页面的开发，变为基于一个个组件进行开发。开发完成后使用 webpack 等工具进行打包构建，并通过基于 Node.js 实现的命令行工具将构建结果发布上线。前端开发开始变得规范化、标准化、工程化。
基于 Node.js 的全栈开发
Node.js 对前端的重要意义还有，以往只能运行在浏览器中的 js 也可以运行在服务器上，前端可以用自己最熟悉的语言来写服务端的代码。于是前端开始使用 Node.js 做全栈开发，开始由前端向全栈的方向转变。这是前端主动突破自己的边界。
另一方面，前端在发展，后端也在发展。也差不多在 Node.js 诞生那个时代，后端普遍开始由巨石应用模式向微服务架构转变。这也就导致以往的前后端分工出现了分歧。随着微服务架构的兴起，后端的接口渐渐变得原子性，微服务的接口也不再直接面向页面，前端的调用变得复杂了。于是 BFF（Backend For Frontend）架构出现了，在微服务和前端中间，加了一个 BFF 层，由 BFF 对接口进行聚合、裁剪后，再输出给前端。而 BFF 这层不是后端本质工作，且和前端的关系最大，所以前端自然而然选择了 Node.js 来实现。这也是当前 Node.js 在服务端较为广泛的应用的原因。

6

巨石应用：大部分web工程是将所有的功能模块(service side)打包到一起并放在一个web容器中运行，很多企业的Java应用程序打包为war包

6

微服务架构：微服务架构是一种架构理念，是指将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。把一个大型的单体应用程序和服务拆分为数个或数十个的微小型服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。
下一代前端开发模式
说完了这几个阶段，可以看到，每一次前端开发模式的变化，都因某个变革性的技术而起。先是 AJAX，而后是 Node.js。那么下一个变革性的技术是什么？不言而喻，个人觉得就是 Serverless。
什么是serverless

目前行业可能更多处在容器 Docker+Kuber***es, 利用
IaaS、PaaS和SaaS 来快速搭建部署应用
基础架构即服务（Infrastructure as a Service，IaaS）、平台即服务（Platform as a Service，PaaS）以及软件即服务（Software as a Service，SaaS）。

6

Docker是一个平台，它主要是提供一些服务，任何一台装有docker的机器你都可以建立、发布、运行你的应用程序，使用docker很省钱省时。

6

简单的介绍Kuber***es。它就是一套成熟的商用服务编排解决方案。Kuber***es定位在Paas层，重点解决了微服务大规模部署时的服务编排问题。
其实 Serverless 早已和前端产生了联系，只是我们可能没有感知。
1、CDN: 相信大家都使用过 CDN，我们开发完成之后，直接将静态文件部署到 CDN 上，通过 CDN 进行内容分发、网络加速，在这个过程中，前端不需要关心 CDN 有多少个节点、如何做负载均衡，也不需要知道 CDN 的 QPS 是多少。所以从这个角度来说，CDN 是一种 serverless 的实现。
2、再比如对象存储，和 CDN 一样，我们只需要将文件上传到对象存储，就可以直接使用了，不需要关心它如何存取文件、如何进行权限控制，所以对象存储对前端来说是 Serverless。
3、甚至一些第三方的 API 服务，也是 Serverless，因为我们使用的时候，不需要去关心服务器。

简单来讲，FaaS（Function as a Service） 就是一些运行函数的平台，比如阿里云的函数计算、AWS 的 Lambda 等。
BaaS（Backend as a Service）则是一些后端云服务，比如云数据库、对象存储、消息队列等。利用 BaaS，可以极大简化我们的应用开发难度。
Serverless 则可以理解为运行在 FaaS 中，使用了 BaaS 的函数。
Serverless 的主要特点有：
1、事件驱动----函数在 FaaS 平台中，需要通过一系列的事件来驱动函数执行。
2、无状态----因为每次函数执行，可能使用的都是不同的容器，无法进行内存或数据共享。如果要共享数据，则只能通过第三方服务，比如 ```Redis`` 等。

6

Redis（全称：Remote Dictionary Server 远程字典服务）是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value[数据库]，并提供多种语言的API。从2010年3月15日起，Redis的开发工作由VMware主持。从2013年5月开始，Redis的开发由Pivotal赞助。
3、无运维----使用serverless我们不需要关心服务器，也不需要关心运维，这也是serverles思想的核心；
4、低成本----使用 Serverless 成本很低，因为我们只需要为每次函数的运行付费。函数不运行，则不花钱，也不会浪费服务器资源过度
基于 Serverless 的前端开发模式
serverless 开发流程
1、在开始具体的案例之前，先看一下传统开发流程。
在传统开发流程中，我们需要前端写页面，后端工程师写接口。后端写完接口之后，把接口部署了，再进行前后端联调。联调完毕后再测试、上线。上线之后，还需要运维工程师对系统进行维护。整个过程涉及多个不同角色，链路较长，沟通协调也是一个问题。
2、而基于 Serverless，后端变得非常简单了，以往的后端应用被拆分为一个个函数，只需要写完函数并部署到 Serverless 服务即可，后续也不用关心任何服务器的运维操作。后端开发的门槛大幅度降低了。因此，只需要一个前端就可以完成所有的开发工作。
当然，前端基于 Serverless 去写后端，最好也需要具备一定的后端知识。涉及复杂的后端系统或者 Serverless 不适用的场景，还是需要后端开发。
serverless带来的价值
1．降低运营复杂度
Serverless架构使软件应用和服务器实现了解耦，服务器不再是用户开发和运营应用的焦点。在应用上线前，用户无须再提前规划服务器的数量和规格。在运维过程中，用户无须再持续监控和维护具体服务器的状态，只需要关心应用的整体状态。应用运营的整体复杂度下降，用户的关注点可以更多地放在软件应用的体验和改进以及其他能带来更高业务价值的地方。
2．降低运营成本
服务器不再是用户关注的一个受管资源，运营的复杂度下降，应用运营所需要投入的时间和人力将大大降低。在最好的情况下，可以做到少数几个应用管理员即可管理一个处理海量请求的应用系统。
3、缩短产品的上市时间
在Serverless架构下，应用的功能被解构成若干个细颗粒度的无状态函数，功能与功能之间的边界变得更加清晰，功能模块之间的耦合度大大减小。这使得软件应用的开发效率更高，应用开发的迭代周期更短。
serverless实践
基于 Serverless 的 BFF (Backend For Frontend)

image.png
传统 BFF (Backend For Frontend) 架构
1、一方面，对不同的设备需要使用不同的 API，另一方面，由于微服务导致前端接口调用的复杂，所以前端开始使用 BFF 的方式，对接口进行聚合裁剪，以得到适用于前端的接口。
2、最底层的就是各种后端微服务，最上层就是各种前端应用。在微服务和应用之前，就是通常由前端开发的 BFF。
-手机端-web端-嵌入式-
这样的架构解决了接口协调的问题，但也带来了一些新的问题。
传统 BFF (Backend For Frontend) 的痛点
比如针对每个设备开发一个 BFF 应用，也会面临一些重复开发的问题。而且以往前端只需要开发页面，关注于浏览器端的渲染即可，现在却需要维护各种 BFF 应用。以往前端也不需要关心并发，现在并发压力却集中到了 BFF 上。总的来说运维成本非常高，通常前端并不擅长运维。
Serverless 则可以帮我们很好的解决这些问题。用Serverless，我们可以用一个个函数来实各个接口的聚合裁剪。前端向 BFF 发起的请求，就相当于是 FaaS 的一个 HTTP 触发器，触发一个函数的执行，这个函数中来实现针对该请求的业务逻辑，比如调用多个微服务获取数据，然后再将处理结果返回给前端。这样运维的压力，就由以往的 BFF Server 转向了 FaaS 服务，前端再也不用关心服务器了。
基于 Serverless 的 BFF 架构
上图则是基于 Serverless 的 BFF 架构。为了更好的管理各种 API，我们还可以添加网关层，通过网关来管理所有 API（比如阿里云的网关），比如对 API 进行分组、分环境。基于 API 网关，前端就不直接通过 HTTP 触发器来执行函数，而是将请求发送至网关，再由网关去触发具体的函数来执行。
API Gateway
在没有API网关作为统一出口的情况下，需要调用方自己组合各种服务，而且容易让调用方感知后端各种服务的存在，各个需要各个做很多相同的工作。
加入API Gateway之后的作用
一般也会把路由，安全，限流，缓存，日志，监控，重试，熔断等都放到 API 网关来做，然后服务层就完全脱离这些东西，纯粹的做业务，也能够很好的保证业务代码的干净，不用关心安全，压力等方面的问题。
基于 Serverless 的服务端渲染
传统服务端渲染
基于当下最流行的三大前端框架（React.js/Anguler/Vue.js），现在的渲染方式大部分都是客户端渲染。页面初始化的时候，只加载一个简单 HTML 以及对应的 JS 文件，再由 JS 来渲染出一个个页面。这种方式最主要的问题就是白屏时间和 SEO 搜索引擎优化
为了解决这个问题，前端又开始尝试服务端渲染。本质思想其实和最早的模板渲染是一样的。都是前端发起一个请求，后端 Server 解析出一个 HTML 文档，然后再返回给浏览器。只不过以往是 JSP、PHP 等服务端语言的模板，现在是基于 React、Vue 等实现的同构应用，这也是如今的服务端渲染方案的优势。
但服务端渲染又为前端带来了一些额外的问题：运维成本，前端需要维护用于渲染的服务器。
基于serverless的服务端渲染
Serverless 最大的优点就是可以帮我们减少运维，那 Serverless 能不能用于服务端渲染呢？当然也是可以的。
传统的服务端渲染，每个请求的 path 都对应着服务端的每个路由，由该路由实现对应 path 的 HTML 文档渲染。用于渲染的服务端程序，就是这些集成了这些路由的应用。
使用 Serverless 来做服务端渲染，就是将以往的每个路由，都拆分为一个个函数，再在 FaaS 上部署对应的函数。这样用户请求的 path，对应的就是每个单独的函数。通过这种方式，就将运维操作转移到了 FaaS 平台，前端做服务端渲染，就不用再关心服务端程序的运维部署了。
基于 Serverless 的小程序开发
1、目前国内使用 Serverless 较多的场景可能就是小程开发了。具体的实现就是小程序云开发，支付宝小程序和微信小程序都提供了云开发功能。
2、在传统的小程序开发中，我们需要前端进行小程序端的开发；后端进行服务端的开发。小程序的后端开发和其他的后端应用开发，本质是是一样的，需要关心应用的负载均衡、备份冗灾、监控报警等一些列部署运维操作。如果开发团队人很少，可能还需要前端去实现服务端。
但基于云开发，就只需要让开发者关注于业务的实现，由一个前端就能够完成整个应用的前后端开发。因为云开发将后端封装为了 BaaS 服务，并提供了对应的 SDK 给开发者，开发者可以像调用函数一样使用各种后端服务。应用的运维也转移到了提供云开发的服务商。
下面分别是使用支付宝云开发的一些例子，函数就是定义在 FaaS 服务中的函数。
负载均衡（Load Balance）其意思就是分摊到多个操作单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任务
备份冗灾：就是为了防止出现自然或者社会灭害带来的对存储设备的损害而造成对数据丢失,而采取的备份.
通用 Serverless 架构
基于上述几个 Serverless 开发的例子，就可以总结出一个通用的 Serverless 架构。


其中最底层就是实现复杂业务的后端微服务（Backend）。然后 FaaS 层通过一系列函数实现业务逻辑，并为前端直接提供服务。对于前端开发者来说，前端可以通过编写函数的方式来实现服务端的逻辑。
同时不管是在后端、FaaS 还是前端，我们都可以去调用云计算平台提供的 BaaS 服务，大大降低开发难度、减少开发成本。小程序云开发，就是直接在前端调用 BaaS 服务的例子。


Serverless的核心目的，就是在云计算的基础上，再向前迈进一步，彻底“包揽”所有的环境工作，直接提供计算服务。
在Serverless架构下，开发者只需编写代码并上传，云平台就会自动准备好相应的计算资源，完成运算并输出结果，从而大幅简化开发运维过程。
换句话说，用户完全不用关心厨房，你把食材提供给Serverless平台，它负责把菜炒好，就这么简单。Serverless的落地案例
接下来，我们不妨通过几个案例，详细看看阿里云Serverless平台究竟是如何提升算力效率的。
阿里巴巴每年的双11促销，是行业公认的算力极限挑战。海量用户、高并发，对系统的处理能力有着极高的要求。
2020 年天猫双 11，阿里云实现了国内首例Serverless在核心业务场景下的大规模落地，扛住了全球最大规模的流量洪峰，创造了Serverless落地应用的里程碑。
今年天猫双 11，阿里云Serverless支撑业务场景更多，范围更广。阿里云函数计算（FC）与集团内的运维体系全面实现标准化对接，打通了研发的最后一公里，首次实现了业务全链路“FaaS+BaaS”的Serverless体系化研发，覆盖淘特、淘系、阿里妈妈、1688、高德、飞猪等业务场景。
根据数据统计，支撑场景数量同比增加2倍，峰值流量总数同比增加3倍，实现了百万QPS的突破，人效提升40%。

再来看看外部用户。
网易云音乐，是阿里云Serverless产品的重要客户之一。
他们的产品背后，有非常多的算法服务支撑，比如多种码率的音频转码、听歌识曲中应用的音频指纹生成和识别、副歌检测、小语种音译歌词等等。
这些任务的资源需求和执行时间变化很大，需要使用C++、Python等多种语言实现，对算力的弹性要求非常大。
早期的时候，网易自建了一个算法服务平台，进行应对。但随着业务增长，以及算法复杂度的不断增加，基础设施管理的负担越来越大，严重影响了工作效率。
引入阿里云Serverless平台之后，网易的算法计算需求得到了很好的满足。网易在函数计算上高峰期一天处理超过2000万个任务，算法应用到业务10倍速的提升，稀疏调用的算法成本大幅缩减。
同样的效率提升，还发生在南瓜电影、越光医疗、世纪华联、江娱互动等企业身上。他们都是阿里云Serverless平台的用户。
7、TCP、UDP、IP详解
一.计算机网络体系结构

1.1 不同网络层对应的协议

1.2 体系分层介绍
●五层协议
○应用层 ：为特定应用程序提供数据传输服务；
■Tel***： 远程登录。
■FTP ：文件传输协议。
■SMTP： 简单邮件传送协议。
■SNMP ：简单网络管理协议。
○传输层 ：为进程提供通用数据传输服务。由于应用层协议很多，定义通用的传输层协议就可以支持不断增多的应用层协议。
■T C P：传输控制协议 （面向流字符的协议 ）。
■U D P：用户数据报协议 。
○网络层 ：为主机提供数据传输服务。而传输层协议是为主机中的进程提供数据传输服务。网络层把传输层传递下来的报文段或者用户数据报封装成分组。
■I P协议：网际协议。
■I C M P协议：I n t e r n e t互联网控 制报文协议。
■I G M P协议：I n t e r n e t组管理协议 。
○数据链路层 ：网络层针对的还是主机之间的数据传输服务，而主机之间可以有很多链路，链路层协议就是为同一链路的主机提供数据传输服务。数据链路层把网络层传下来的分组封装成帧。
○物理层 ：考虑的是怎样在传输媒体上传输数据比特流，而不是指具体的传输媒体。物理层的作用是尽可能屏蔽传输媒体和通信手段的差异，使数据链路层感觉不到这些差异。
●OSI
○表示层 ：数据压缩、加密以及数据描述，这使得应用程序不必关心在各台主机中数据内部格式不同的问题。
○会话层 ：建立及管理会话。
■prc协议：(远程方法调用协议)
●TCP/IP
●它只有四层，相当于五层协议中数据链路层和物理层合并为网络接口层。
TCP/IP 体系结构不严格遵循 OSI 分层概念，应用层可能会直接使用 IP 层或者网络接口层。
1.3 数据封装
●元数据进行网络传输，需要先进行逐层封装和逐层解析的过程，如下图：
●向下的过程中，需要添加下层协议所需要的首部或者尾部，而在向上的过程中不断拆开首部和尾部。
路由器只有下面三层协议，因为路由器位于网络核心中，不需要为进程或者应用程序提供服务，因此也就不需要传输层和应用层。
1.4 协议与上下层的关系简图

二.IP协议
2.1 引言
●IP协议在OSI七层协议中位于网络层，在物理层和链路层之上，本文的研究范围为网络层到应用层之间的上层协议，对下层协议暂不研究。所以就以IP层为切入点，
●网络层是整个互联网的核心，使用 IP 协议，可以把异构的物理网络连接起来，使得在网络层看起来好像是一个统一的网络。
2.2 概述
I P是T C P / I P协议族中最为核心的协议。所有的 T C P、U D P、I C M P及I G M P数据都以I P数据 报格式传输 ；IP数据报传送 服务 具有不可靠性、无连接性。
●不可靠（u n r e l i a b l e） ：的意思是它不能保证 I P数据报能成功地到达目的地。 I P仅提供最好 的传输服务。如果发生某种错误时，如某个路由器暂时用完了缓冲区， I P有一个简单的错误 处理算法：丢弃该数据报，然后发送 I C M P消息报给信源端。任何要求的可靠性必须由上层来 提供（如T C P）
●无连接（c o n n e c t i o n l e s s）这个术语的意思是 I P并不维护任何关于后续数据报的状态信息。 每个数据报的处理是相互独立的。这也说明， I P数据报可以不按发送顺序接收。如果一信源 向相同的信宿发送两个连续的数据报（先是 A，然后是B），每个数据报都是独立地进行路由 选择，可能选择不同的路线，因此 B可能在A到达之前先到达。
●与 IP 协议配套使用的还有三个协议：
○地址解析协议 ARP（Address Resolution Protocol）
○网际控制报文协议 ICMP（Inter*** Control Message Protocol）
○网际组管理协议 IGMP（Inter*** Group Management Protocol）
2.3 IP分类
1I P地址长为32 bit，地址具有一定的结构，五类不同 的互联网地址格式下
2各类IP地址的范围

1有三类I P地址：
○单播地址（目的为单个主机）
○广播地址（目的端为给定网络上的所有主 机）
○多播地址（目的端为同一组内的所有主机）
2.4 IP 数据报格式
●ip地址长度为32bit，普通的I P首部长为2 0个字节。
18位生存时间TTL
○T T L（t i m e - t o - l i v e）生存时间字段设置了数据报可以经过的最多路由器数。它指定了数据 报的生存时间。T T L的初始值由源主机设置（通常为 3 2或6 4），一旦经过一个处理它的路由器， 它的值就减去 1。当该字段的值为 0时，数据报就被丢弃，并发送 I C M P报文通知源主机。
216位手部检验和
○用于验证传送数据报和接受数据报的差异。首先把检验和字段置为 0。 对首部中每个 16 bit 进行二进制反码求和 ，结果存在检验和字段中 。收到数据报后再对首部进行计算，相同就把检验和字段置为 1，不同那么I P就丢弃收到的 数据报 。但是不生成差错报文，由上层去发现丢失的数据报并进行重传。
3总长度：占用16位二进制位，总长度字段是指整个IP数据报的长度（报头区+数据区）
2.5 IP路由选择
当一个IP数据包准备好了的时候，IP数据包(或者说是路由器)是如何将数据包送到目的地的呢?它是怎么选择一个合适的路径来"送货"的呢?
1最特殊的情况是目的主机和主机直连，那么主机根本不用寻找路由，直接把数据传递过去就可以了。至于是怎么直接传递的，这就要靠ARP协议了，后面会讲到。
2稍微一般一点的情况是，主机通过若干个路由器(router)和目的主机连接。那么路由器就要通过ip包的信息来为ip包寻找到一个合适的目标来进行传递，比如合适的主机，或者合适的路由。路由器或者主机将会用如下的方式来处理某一个IP数据包
○如果IP数据包的TTL(生命周期)以到，则该IP数据包就被抛弃。
○搜索路由表，优先搜索匹配主机，如果能找到和IP地址完全一致的目标主机，则将该包发向目标主机
○搜索路由表，如果匹配主机失败，则匹配同子网的路由器，这需要“子网掩码(1.3.)”的协助。如果找到路由器，则将该包发向路由器。
○搜索路由表，如果匹配同子网路由器失败，则匹配同网号(第一章有讲解)路由器，如果找到路由器，则将该包发向路由器。
○搜索陆游表，如果以上都失败了，就搜索默认路由，如果默认路由存在，则发包
○如果都失败了，就丢掉这个包。
这再一次证明了，ip包是不可靠的。因为它不保证送达。
2.6 子网寻址
1IP地址的定义是网络号+主机号。但是现在所有的主机都要求子网编址，也就是说，把主机号在细分成子
网号+主机号。最终一个IP地址就成为 网络号码+子网号+主机号。
a下面就是一个B类地址： 
bB类网络地址 （1 4 0 . 2 5 2），在剩下的16 bit中，8 bit用于子网号，8 bit用于主机号。这样就允许有
2 5 4个子网，每个子网可以有2 5 4台主机。 （8位一共有256种可能，由于全0或全1的主机号都是无效的， 所以就有254种可能）。
2.7 地址解析协议 ARP
●网络层实现主机之间的通信，而链路层实现具体每段链路之间的通信。因此在通信过程中，IP 数据报的源地址和目的地址始终不变，而 MAC 地址随着链路的改变而改变。
●网络层实现主机之间的通信，而链路层实现具体每段链路之间的通信。因此在通信过程中，IP 数据报的源地址和目的地址始终不变，而 MAC 地址随着链路的改变而改变。
ARP 实现由 IP 地址得到 MAC 地址。
每个主机都有一个 ARP 高速缓存，里面有本局域网上的各主机和路由器的 IP 地址到 MAC 地址的映射表。
如果主机 A 知道主机 B 的 IP 地址，但是 ARP 高速缓存中没有该 IP 地址到 MAC 地址的映射，此时主机 A 通过广播的方式发送 ARP 请求分组，主机 B 收到该请求后会发送 ARP 响应分组给主机 A 告知其 MAC 地址，随后主机 A 向其高速缓存中写入主机 B 的 IP 地址到 MAC 地址的映射。
2.8 网际控制报文协议 ICMP
1I C M P经常被认为是 I P层的一个组成部分。它传递差错报文以及其他需要注意的信息。 I C M P报文通常被I P层或更高层协议（ T C P或U D P）使用。一些 I C M P报文把差错报文返回给 用户进程。
2当传送IP数据包发生错误－－比如主机不可达，路由不可达等等，ICMP协议将会把错误信息封包，然后传送回给主机。给主机一个处理错误的机会，这 也就是为什么说建立在IP层以上的协议是可能做到安全的原因。ICMP数据包由8bit的错误类型和8bit的代码和16bit的校验和组成。而前 16bit就组成了ICMP所要传递的信息。书上的图6－3清楚的给出了错误类型和代码的组合代表的意思。
3尽管在大多数情况下，错误的包传送应该给出ICMP报文，但是在特殊情况下，是不产生ICMP错误报文的。如下 :(所有的这一切规定，都是为了防止产生ICMP报文的无限传播而定义的。 )
○ICMP差错报文不会产生ICMP差错报文（出IMCP查询报文）（防止IMCP的无限产生和传送）
○目的地址是广播地址或多播地址的IP数据报。
○作为链路层广播的数据报。
○不是IP分片的第一片。
○源地址不是单个主机的数据报。这就是说，源地址不能为零地址、环回地址、广播地 址或多播地址。
4ICMP协议大致分为两类，一种是查询报文，一种是差错报文。其中查询报文有以下几种用途 :
○ping查询
○网掩码查询（用于无盘工作站在初始化自身的时候初始化子网掩码）
○时间戳查询（可以用来同步时间)。 ICMP 报文分为差错报告报文和询问报文。
1. Ping
Ping 是 ICMP 的一个重要应用，主要用来测试两台主机之间的连通性。
Ping 的原理是通过向目的主机发送 ICMP Echo 请求报文，目的主机收到之后会发送 Echo 回答报文。Ping 会根据时间和成功响应的次数估算出数据包往返时间以及丢包率。
2. Traceroute
Traceroute 是 ICMP 的另一个应用，用来跟踪一个分组从源点到终点的路径。
Traceroute 发送的 IP 数据报封装的是无法交付的 UDP 用户数据报，并由目的主机发送终点不可达差错报告报文。
●源主机向目的主机发送一连串的 IP 数据报。第一个数据报 P1 的生存时间 TTL 设置为 1，当 P1 到达路径上的第一个路由器 R1 时，R1 收下它并把 TTL 减 1，此时 TTL 等于 0，R1 就把 P1 丢弃，并向源主机发送一个 ICMP 时间超过差错报告报文；
●源主机接着发送第二个数据报 P2，并把 TTL 设置为 2。P2 先到达 R1，R1 收下后把 TTL 减 1 再转发给 R2，R2 收下后也把 TTL 减 1，由于此时 TTL 等于 0，R2 就丢弃 P2，并向源主机发送一个 ICMP 时间超过差错报文。
●不断执行这样的步骤，直到最后一个数据报刚刚到达目的主机，主机不转发数据报，也不把 TTL 值减 1。但是因为数据报封装的是无法交付的 UDP，因此目的主机要向源主机发送 ICMP 终点不可达差错报告报文。
●之后源主机知道了到达目的主机所经过的路由器 IP 地址以及到达每个路由器的往返时间。
三.UDP协议
3.1 概述
1UDP是一个简单的面向数据报的运输层协议：进程的每个输出操作都正好产生一个 U D P 数据报，并组装成一份待发送的 I P数据报。 这与面向流字符的协议不同，如 T C P，应用 程序产生的全体数据与真正发送的单个 I P数据报可能没有什么联系。
2用户数据报协议 UDP（User Datagram Protocol）是无连接的，尽最大可能交付，没有拥塞控制，面向报文（对于应用程序传下来的报文不合并也不拆分，只是添加 UDP 首部），支持一对一、一对多、多对一和多对多的交互通信。
注意： UDP是传输层协议，和TCP协议处于一个分层中，但是与TCP协议不同，UDP协议并不提供超时重传，出错重传等功能，也就是说其是不可靠的协议。
3.2 UDP首部
1UDP的首部占8个字节如下图：
2在ip首部为20个字节，由于数据封装是逐层进行的所有UDP的数据报为下图：
3UDP端口号
○由于很多软件需要用到UDP协议，所以UDP协议必须通过某个标志用以区分不同的程序所需要的数据包。端口号的功能就在于此，例如某一个UDP程序A在系统中注册了3000端口，那么，以后从外面传进来的目的端口号为3000的UDP包都会交给该程序。端口号理论上可以有2^16这么多。因为它的长度是16个bit
4UDP检验和
○U D P和T C P在首部中都有覆盖它们首部和数据的检验和。 U D P的检验和是可选的，而T C P 的检验和是必需的。 （伪首部的长度为12个字节，所以TCP的长度一定为20）
○UDP检验和覆盖UDP协议头和数据，这和IP的检验和是不同的，IP协议的检验和只是覆盖IP数据头，并不覆盖所有的数据。UDP和TCP都包含一个伪首部，这是为了计算检验和而摄制的。伪首部甚至还包含IP地址这样的IP协议里面都有的信息，目的是让UDP两次检查数据是否已经正确到达目的地。如果发送端没有打开检验和选项，而接收端计算检验和有差错，那么UDP数据将会被悄悄的丢掉（不保证送达），而不产生任何差错报文。
3.3 UDP长度
1理论上，I P数据报的最大长度是64K(65535字节)（2的16次幂），这是由I P首部16比特总长度字段所 限制的。去除 2 0字节的IP首部和8个字节的U D P首部，U D P数据报中用户数据的最长长度为 65507字节。但是一般网络在传送的时候，一次一般传送不了那么长的协议（涉及到MTU的问题），就只好对数据分片，当然，这些是对UDP等上级协议透明的，UDP不需要关心IP协议层对数据如何分片 。
2在一个以太网上，数据帧的最大长度是 1 5 0 0字节 , 其中1 4 7 字节留给数据，假定 I P首部为2 0字节， 而且U D P首部为8字节，所以每片UDP最大数据为1472个字节
3另外需要解释几个术语： I P数据报是指 I P层端到端的传输单元（在分片之前和重新组装 之后），分组是指在I P层和链路层之间传送的数据单元。一个分组可以是一个完整的 I P数据报， 也可以是I P数据报的一个分片。
3.4 UDP服务器设计
UDP协议的某些特性将会影响我们的服务器程序设计，大致总结如下：
1关于客户IP和地址：服务器必须有根据客户IP地址和端口号判断数据包是否合法的能力（这似乎要求每一个服务器都要具备）
2关于目的地址：服务器必须要有过滤广播地址的能力。
3关于数据输入：通常服务器系统的每一个端口号都会和一块输入缓冲区对应，进来的输入根据先来后到的原则等待服务器的处理，所以难免会出现缓冲区溢出的问题，这种情况下，UDP数据包可能会被丢弃，而应用服务器程序本身并不知道这个问题。
4服务器应该限制本地IP地址，就是说它应该可以把自己绑定到某一个网络接口的某一个端口上。
3.5 UDP的应用
 三种 I P地址：单播地址、广播地址和多播地址 ，广播和多播仅应用于 U D P
单播， 广播，多播
1概念：有时一个主机要向网上的所有其他主机发送帧， 这就是广播 ，多播 (multicast) 处于单播和广播之间：帧仅传送给属于多播组的 多个主机。
2广播和多播仅应用于 U D P，它们对需将报文同时传往多个接收者的应用来说十分重要 ，T C P是一个面向连接的协议，它意味着分别运行于两主机（由 I P地址确定）内的两进程（由 端口号确定）间存在一条连接。
3I P多播提供两类服务：
○向多个目的地址传送数据。有许多向多个接收者传送信息的应用：例如交互式会议系 统和向多个接收者分发邮件或新闻。如果不采用多播，目前这些应用大多采用 T C P来完成 （向每个目的地址传送一个单独的数据复制）。然而，即使使用多播，某些应用可能继续采用 T C P来保证它的可靠性。
○客户对服务器的请求。例如，无盘工作站需要确定启动引导服务器。目前，这项服务 是通过广播来提供的，但是使用多播可降低不提供这项服务主机的负 担。
四.TCP协议
4.1 引言
1尽管TCP和UDP都使用相同的网络层（I P），TCP却向应用层提供与UDP完全不同的服务。 TCP提供一种面向连接的、可靠的字节流服务。 所以TCP要比UDP可靠的多，UDP是把数据直接发出去，而不管对方是不是在收信，就算是UDP无法送达，也不会产生ICMP差错报文（ICMP：2.8小结）。
4.2 TCP的服务
●TCP保证可靠性的简单工作原理如下 ：
○应用数据被分割成T C P认为最适合发送的数据块。这和 U D P完全不同，应用程序产生的 数据报长度将保持不变。由 T C P传递给I P的信息单位称为报文段或段（ s e g m e n t）（参见 图1 - 7）。在1 8 . 4节我们将看到T C P如何确定报文段的长度。
○当T C P发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能 及时收到一个确认，将重发这个报文段。在第 2 1章我们将了解T C P协议中自适应的超时 及重传策略。
○当T C P收到发自T C P连接另一端的数据，它将发送一个确认。这个确认不是立即发送， 通常将推迟几分之一秒，这