架构演进历经如下变化：
大型机（Mainframe）
原始分布式（Distributed）
大型单体（Monolithic）
面向服务（Service-Oriented）
微服务（Microservice)
服务网格（Service Mesh）
无服务（Serverless）
服务架构演进史：
原始分布式时代
20世纪70年代（1970s ）- 20世纪80年代（1980s）大型机-->微型机转换
微型计算机 16位寻址，不足5MHz时钟频率，128KB左右内存。
eg：
Intel 8086处理机 1978年研制成功，持续到80年代中期，90年代初仍有销售
计算机硬件运算能力有限。
为突破算力限制，开始寻找使用多台计算机共同协作，支撑同一套软件系统的可行方案。这一阶段就是原始的分布式探索。
eg：
NCA 网络运算架构（Network Computing Architecture，NCA）（惠普公司）远程服务调用雏形
AFS （Andrew File System，Andrew 文件系统）（卡内基·梅隆大学）分布式文件系统最早实现。（Andrew含义为纪念Andrew Carnegie和Andrew Mellon）
Kerberos协议（由 麻省理工学院 开发）服务认证和访问控制的基础性协议。分布式服务安全性的重要支撑。（目前Windows和Mac OS等操作系统登录仍然被使用的认证功能）
DCE 分布式运算环境 （Distributed Computing Environment，DCE）的分布式技术体系。（开放软件基金会（Open Software Foundation，OSF，即后来的 国际开发标准组织 ）邀请当时的主流计算机厂商一群参与，共同制定的分布式技术体系）。
DCE 包含一套相对完整的分布式组件规范与参考实现：
eg：
远程调用的鼻祖：
RPC （当时称为DCE/RPC ）远程服务调用规范（Remote Procedure Call，RPC）（源自NCA）；
ONC RPC 远程调用服务标准（由Sun公司 向 互联网工程任务组（Internet Engineering Task Force，IETF）提交）
ONC (Open Network Computing) RPC (Remote Procedure Call) is an open source RPC framework developed by Sun Microsystems. DCE (Distributed Computing Environment) is an architecture defined by the Open Software Foundation (OSF). Both technologies support client-server applications in heterogeneous distributed environments.
https://www.ibm.com/docs/en/cics-ts/5.5?topic=programs-onc-dce-concepts
分布式文件系统规范：
DFS 分布式文件系统（Distributed File System，DFS）（源自AFS）。当时称为DCE/DFS。
服务认证规范（源自Kerberos）
麻省理工学院开发的安全认证系统，如上介绍。
时间服务
分布式计算系统有很多优点，但也带来了新的问题。比如，不同节点上的时钟同步。在单个系统中，有一个时钟为所有应用程序提供一天中的时间。计算机硬件时钟并不完全准确，但对于系统上运行的所有进程的时间总是希望一致。
DCE 分布式时间服务 (DTS) 通过两种方式解决此问题：
1. DTS 提供了一种在分布式系统中定期同步不同主机上的时钟的方法。
2. DTS 还提供了一种使同步的时间概念与正确时间保持合理接近的方法。（在 DTS 中，正确的时间被认为是国际标准协调世界时 (UTC)。）
命名与目录服务
Introduction to the DCE Directory Service
UUID 通用唯一标识符（Universally Unique Identifier，UUID）
UUIDs (Universally Unique IDentifier)，也称为 GUIDs (Globally 唯一标识符）。UUID 长 128 位，不需要在中心注册的过程。
根据标准方法生成时，UUID 出于实用目的是唯一的。与大多数其他编号方案不同，它们的唯一性不依赖于中央注册机构或生成它们的各方之间的协调。虽然UUID 被复制的概率不是零，但它足够接近零，可以忽略不计。[2] [3]
- 版本 1（日期时间和 MAC 地址）
- 版本 2（日期时间和 MAC 地址，DCE 安全版本）
- 版本 3 和 5（基于命名空间名称）
- 版本 4（随机）
https://datatracker.ietf.org/doc/html/rfc4122
https://datatracker.ietf.org/doc/html/rfc4122
UNIX分布式设计哲学：保持接口与实现的简单性，比系统的任何其他属性，包括准确性、一致性和完整性，都来得更加重要。
-------------Richard P. Gabriel, The Rise of Worse is Beterr, 1991
当时的设计原则是分布式环境中的服务调用、资源访问、数据存储等尽可能透明化、简单化
调用远程方法 vs 调用本地方法
网络环境下的一系列新问题：
远程服务在哪里？（服务发现）
远程服务有多少个？（负载均衡）
网络出现分区、超时或者服务出错了怎么办?（熔断、隔离、降级）
方法的参数与结果如何表示？（序列化协议）
信息如何传输？（传输协议）
服务权限如何管理？（认证、授权）
如何保证通信安全？（网络安全层）
如何令调用不同机器的服务返回相同的结果?(分布式数据一致性)
DCE 从零开始，从无到有的回答了其中的大部分问题，构建出大量的分布式基础组件与协议，尽力做到了相对的 “透明”。
原始分布式时代的教训是：
某个功能能进行分布式，并不意味着它就应该进行分布式，强行追求透明的分布式操作，只会自寻苦果。
------Kyle Brow，IBM Fellow， Beyond Buzzwords：A Bref History of Microservices
Patterns, 2016
两条通往更大规模软件系统的道路：
1.尽快提升单机的处理能力，以避免分布式的种种问题
2.找到更完美的、解决如何构建分布式系统的解决方案。
单体时代：
20世纪80年代（1980s）摩尔定律稳定发挥作用的黄金时期，微信计算机的性能每两年增长一倍的速度惊人提升，硬件算了束缚软件规模的链条变得松动，信息系统进入以单台或少量几台计算机即可作为服务器来支撑大型信息系统运作的单体时代。在很长的时间内，单体都是软件架构的绝对主流。
另外一条道路探索从未中断。
原始分布式时代提出的构建符合UNIX设计哲学、如同本地调用一般简单透明的分布式系统这个目标，是软件开发者对分布式系统最初的美好愿景，但迫于现实，他会在一定时期内被妥协、被舍弃。
分布式架构经过一段越来越复杂的发展过程。
21世纪10年代（2010s），随着分布式架构逐渐成熟、完善，并逐渐取代大型软件的主流架构风格。
单体系统时代：
单体架构是今天绝大多数软件开发者都学习、实践过的一种软件架构，许多介绍微服务的图书和技术资料中也把这种架构风格的应用，称作“巨石系统”（Monolithic Appplication）。
单体架构 在整个软件架构演进的历史进程里，出现的最早、应用范围最广、使用人数最多、统治时间最长的一种架构风格。
但单体这个名称，是在微服务流行之后，“事后追认” 所形成的的概念。此前，没有多少人将“单体”看作一种架构。很少有教如何开发单体架构的开发资料。这一方面体现单体架构的简单性，另外一方面体现出在相当长时间里，大家已经习惯了软件架构就是单体的这种样子。
单体不一定就不好，一般有问题的是“大型单体系统”，而不是小型单体系统。
对于小型系统，单台机器足以支撑起良好的运行系统，不仅易于开发、测试、部署，而且系统中各个功能、模块、方法的调用都是进程内调用，不会发生进程间通信（Inter-Process Communication, IPC）,因此，运行效率也是最高的
单体系统的不足，必须在软件的性能需求超过了单机、软件人员规模明显超过了“2张披萨”（2 Pizza Team）范畴前提下才有讨论的价值。
单体系统一般也是分层的。分层架构（Layered Architecture）是现在所有系统中普遍认可，采用的软件设计方法，无论是单体还是微服务，亦或是其他架构风格，都会对代码进行纵向层次划分。
如果常见的：表示层-》业务层-》持久层-》数据库层
另外，单体架构也支持按照技术、功能、职责等维度，将软件拆分为各种模块，以便重用和管理代码。单体系统并不意味只有一个整体的程序封装形式，如果需要，它完全可以由多个JAR，WAR，DDL，Assembly 或者其他模块格式来构成。即使从横向扩展（Scale Horizontally）角度衡量，在负载均衡器之后同时部署若干个单体副本系统，以达到分摊流量压力的效果。
单体系统缺陷：
好处：单体系统所有代码运行在同一个进程内，所有模块、方法的调用都无须考虑网络分区、对象复制的性能损失。进程内的调用简单、高效。
缺点：任何一部分代码出现缺陷，过度消耗进程空间内的资源，所造成的营销也是全局性的，难以隔离的。
譬如：内存泄露、线程爆炸、阻塞、死循环等问题，不仅仅影响某个一个功能、模块的正常运作，还会影响整个程序。
如果出问题的是某些更高层次的公共资源，譬如端口号或者数据库连接池泄露，还将会影响整台机器甚至集群中其他单体副本的正常工作。
由于隔离能力的缺失，单体难以阻断错误传播、不便于动态更新程序。还面临难以技术异构的困难，每个模块的代码通常都需要使用一样的程序语言，乃至一样的框架去开发。
微服务取代单体的最重要原因：单体系统架构风格要求每一个部件、每一处代码都尽量可靠，尽量不出或少出缺陷。然而,当系统规模越来越大时，交付一个可靠的单体系统就变得越来越具有挑战性。软件架构的演进，构建可靠系统的观念“追求尽量不出错”到正视“出错是必然”的转变，才是微服务架构得以挑战并逐步取代单体架构的主要原因。
允许程序出错，获得自治与隔离能力，以及可以实现技术异构等目标，是继性能与算力之后，让程序再次选择分布式的理由。SOA 就是曾经的探索过的方法之一。新旧世纪之交（20世纪-21世纪）用来对一个大的单体系统拆分为若干个更小的，不运行在同一进程的独立服务，这些服务的拆分方法后来带来了面向服务架构的一段兴盛期。
SOA 时代：
SOA 面向服务架构（Service-Oriented Architecture）
对大型单体系统进行拆分，让每一个子系统都能独立的部署、运行、更新。下面有三种较有代表的架构模式：
- 烟囱式架构（Information Silo Architecture）
- 微内核架构 （Microkernel Architecture）
- 事件驱动架构（Event-Driven Architecture）
烟囱式架构（Information Silo Architecture）：也称为孤岛式信息系统或者烟囱式信息系统。指的是一种与其他相关系统完全没有互操作或者协调工作的设计模式。
这种系统其实没有“架构设计”可言。企业中两个部门真的完全没有任何交互？系统的人员、组织、权限是否完全独立、没有任何重叠么？
微内核架构 （Microkernel Architecture）：微内核架构也称为插件式架构（Plug-in Architecture）。需要共享的主数据，连同其他可能被子系统用到的公共服务、数据、资源集中到一块，组成一个被所有业务系统共同依赖的核心（Kernel，也称为Core System），具体的业务系统以插件模块（Plug-in Module）的形式存在，这样可以也可提供可扩展的、灵活的、天然隔离的功能体系，即微内核架构。
这种架构适合桌面应用程序，也经常在web程序中使用，以及部分App
任何计算机系统都是由各种软件互相配合来实现具体功能的。不同架构实现的软件都可以视作整个系统的某种插件。
平台型应用，如果希望将新特性或者新功能及时加入系统，微内核架构是不错的选择。
微内核架构也可以嵌入其他架构模式中，通过插件的方式来提供新功能的定制开发能力。
微内核架构也有局限性，它假设系统中各个模块之间直接互不认识，且不可预知系统安装哪些模块，因此这些插件可以访问内核中的一些公共资源，但不会直接交互。
事件驱动架构（Event-Driven Architecture）：
为了让子系统互相通讯，一种可行的方案是在子系统之间建立一套事件队列管道（Event Queue），来自外部的消息以事件的形式发送至管道总，各个子系统从管道里获取自己感兴趣，能够处理事件消息，也可以为事件新增或者修改其中附加信息，甚至可以自己发布一些新的事件到管道队列中去。
每一条消息的处理者都是独立的、高度解耦的，但又能与其他处理者通过事件管道进行交互。
SOA：
1994年：SOA概念最早由Gartner公司于1994年提出。（当时SOA还不具备发展条件）
2006年 ：OSOA （Open Service Oriented Architecture）联盟成立（IBM、Oracle、SAP等公司共同成立）。联合制定和推进SOA相关行业标准
2007年：Open CSA（Open Composite Service Architecture，Open CSA）组织，SOA的官方管理机构成立。OASIS 结构化标准促进组织 （Organization for the Advancement of Structured Information Standard，OASIS）。在OASIS的倡议和支持下，OSOA 由软件厂商组成的松散组织，转变为一个制定行业标准的国家组织，并联合OASIS共同成立了Open CSA（Open Composite Service Architecture，Open CSA）组织，这就是SOA的官方管理机构
Elements of SOA, by Dirk Krafzig, Karl Banke, and Dirk Slama[26]
SOA meta-model, The Linthicum Group, 2007
SOA软件架构时代，包含了许多概念、思想，在今天的微服务中有能找到对应的身影，譬如：
服务之间的松散耦合、注册、发现、治理、隔离、编排等。
SOA 对这些问题，包括“软件开发”，都指导的更具体，更系统，如下：
更具体：
- SOA本身属于抽象概念，不是某一种具体的技术
- 比单体架构、烟囱式架构（Information Silo Architecture）、微内核架构 （Microkernel Architecture）、事件驱动架构（Event-Driven Architecture）操作性更强。
- 不能简单的认为是一种架构风格，更是一套软件设计的基础平台
- 有清晰的指导原则：eg：服务的封装性、自治、松耦合、可重用、可组合、无状态等等
- 采用SOAP作为远程调用协议，依靠SOAP协议族（WSDL、UDDI和WS-*协议）来完成服务的发布、发现和治理。
- 利用ESB企业服务总线（Enterprise Service Bus，ESB）的消息管道来实现各个子系统之间的交互，令各服务在ESB的调度下无须相互依赖就能相互通信，实现了服务的松耦合，也为后续进一步实现业务流程编排（Business Process Management，BPM)提供了基础。
- 使用服务数据对象（Service Data Object， SDO）来访问和表示数据
- 使用服务组件架构（Service Component Architecture， SCA）来定义服务封装的形式和服务运行的容器。
更系统：
- SOA终极目标希望总结出一套自上而下的软件研发方法论，做到企业只需要跟着SOA的思路，就能一揽子解决掉开发过程中的全部问题。譬如：该如何挖掘需求、如何将需求分解为业务能力、如何编排已有服务、如何开发/测试/部署新的功能等。
- SOA还关注研发过程涉及的需求、管理、流程和组织。
SOA 21世纪最初的10年里曾盛行一时，有IBM等一众行业巨头厂商为其呐喊冲锋，吸引了不少软件开发厂商，尤其企业级开发商，但最终还是偃旗息鼓，沉寂下去。
SOAP协议被逐渐边缘化的原因：
- 简单说就太复杂了。
- 过于严格的规范定义带来过度的复杂性，而构建在SOAP基础上的ESB、BPM、SCA、SDO等诸多上层建筑加剧了这种复杂性。
- 过于精密的流程和理论需要懂得复杂概念的专业人员才能驾驭。
- 可以实现多个异构大型系统之间的复杂集成交互，却很难作为一种广泛普适性的软件架构风格来推广。
微服务时代：
微服务是一种通过多个小型服务组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准构建。
各个服务可以采用不同的编程语言、不同的数据存储技术，运行在不同的进程之中。
服务采取轻量级的通信机制和自动化的部署机制实现通信与运维。
微服务的九个核心业务和技术特征：
- 围绕业务能力构建（Organized around Business Capability）
- 分散治理（Decentralized Governance）
- 通过服务来实现独立自治的组件（Componentization via Service）
- 产品化思维（Product not Project）
- 数据去中心化（Decentralized Data Management）
- 强终端弱管道（Smart Endpoint and Dumb Pipe）
- 容错性设计（Design for Failure）
- 演进式设计（Evolutonary Design）
- 基础设施自动化（Infrastructure Automation）
围绕业务能力构建（Organized around Business Capability）
康威定律：有怎样结果、规模、能力的团队，就会产生对于结构、规模、能力的产品
团队和产品拥有一致的结构
分散治理（Decentralized Governance）
服务对应的开发团队有对服务运行质量负责的责任，以及不受外界干预的掌控服务的各个方面的权利。譬如选择与其他服务异构的技术来实现自己的服务。
eg：大多数公司，通常会统一的主流语言。技术栈或专有技术平台。
微服务强调在确实需要技术异构时，应能够选择“不统一”的权利。eg：人工训练选择Python
通过服务来实现独立自治的组件（Componentization via Service）
强调通过“服务”（Service）而不是“类库”（Library）来构建组建。类库在编译期静态链接到程序中，通过本地调用来提供功能，而服务时进程外组件，通过远程调用提供功能。
尽管远程服务调用成本更高，但这是为组件带来自治与隔离的能力的必要代价。
产品化思维（Product not Project）
避免把软件研发视作要去完成的某种功能，而是视作一种持续改进、提升的过程。
微服务下，要求开发团队每个人都具有产品化思维，关心整个产品的全部方面是具有可行性的。
数据去中心化（Decentralized Data Management）
提倡数据按领域分散管理、更新、维护、存储。
不同领域关注的是不同内容，如果都映射到同一个实体，可能使不同服务相互影响而丧失独立性。
分布式处理好一致性很困难，很多时候没有办法使用传统的事务处理来保证，但是两害取其轻，即使有一些必要的代价，但仍是值得使用的。
强终端弱管道（Smart Endpoint and Dumb Pipe）
弱终端（Dumb Pipe）几乎是直接反对SOAP和ESB的通信机制。
ESB相关：
ESB可以处理的消息的编码加工、业务规则转换等；
BPM可以集中编排企业业务服务；
SOAP有几十个WS-*协议族在处理事务、一致性、认证授权等一系列工作，这些构建在通信管道上的功能也许对某个系统中的某一部分服务是必要的，但是对另外更多的服务则是强加进来的负担。
如果服务需要上面的额外通信能力，就应该在服务自己的Endpoint上解决，而不是在通信管道上面一揽子处理。
微服务相关：
微服务提倡使用类似经典UNIX过滤器那样简单直接的通信方式，所以RESTful风格通信在微服务中会是更合适的选择。
容错性设计（Design for Failure）
不再虚幻地追求服务永远稳定，而是接受服务总会出错的现实，要求在微服务的设计中，能够有自动的机制对其依赖的服务进行快速故障检测，在持续出错的时候进行隔离，在服务恢复的时候重新联通。
所以，”断路器“这类设施，对实际生产环境中的微服务来说并不是可选的外围组件，而是一个必需的支撑点。没有容错设计，系统很容易被一两个服务崩溃所带来的雪崩效应淹没。
可靠系统完全有可能是由会出错的服务组成，这是微服务的最大价值所在。
演进式设计（Evolutonary Design）
容错设计承认服务会出错，演进式设计则承认服务会报废淘汰。
一个设计良好的服务，应该是能够报废的，而不是期望得到长存永生。
假如系统中出现不可更改，无可替代的服务，这并不能说明这个服务多么优秀，多么重要反而是一种系统设计上脆弱的表现，微服务所追求自治、隔离，也是发对这种脆弱性的表现。
基础设施自动化（Infrastructure Automation）
基础设施自动化，如CI/CD的长足发展，显著减少了构建、发布、运维工作的复杂性。
由于微服务架构下运维对象数量是单体架构运维对象数量的数量级倍，使用微服务的团队更加依赖于基础服务设施的自动化，人工很难支持成百上千乃至上万级别的服务的。
微服务对比SOA：
微服务追求的是更加自由的架构风格，摈弃了几乎所有的SOA里可以抛弃的约束和约定，提倡以“实践标准”代替“规范标准”。
分布式问题会有不同的解决方案。对于服务的注册发现、跟踪治理、负载均衡、故障隔离、认证授权、伸缩扩展、传输通信、事务处理等问题、微服务将不再有统一的解决方案。
eg：
远程调用：Java范围内的微服务，服务间远程调用问题，解决方案候选清单：RMI(Sun/Oracle)
,Thrift(Facebook), Dubbo(Alibaba), gRPC(Google), Motan2(sina), Finagle(Twitter), brpc(百度), Arvo（Hadoop）, JSON-RPC, REST, etc.
服务发现：可选择的清单：Eureka（Netflix）， Consul（HashiCorp）， Nacos（Alibaba）， ZooKeeper（Apache）， etcd（CoreOS）， CoreDNS（CNCF）， etc.
微服务的自由：
优点：没有SOA定下的负载技术标准，有自己选择的权利。不用背负SOA沉重的框架。
需要解决什么问题，就引入什么框架。
团队熟悉什么技术，就使用什么框架。
另外使用类似Spring Cloud这样胶水式的全家桶工具集，通过一致的接口、声明和配置，进一步屏蔽来自具体工具、框架的复杂性，降低了在不同工具、框架直接切换的成本。
对普通“螺丝钉”式的程序员，微服务架构师友善的。
缺点： 对架构者要求高，容易选择迷茫
对架构者，架构能力的要求已经上升到史无前例的程度。
对架构者知识面面的要求非常高：架构者的第一职责就是决策权衡，有利有弊才需要决策，有取有舍才需要权衡， 如果架构者本身的知识面不足以覆盖所需要决策的内容，不清楚其中利弊，会陷入选择困难症的境遇中。
后微服务时代：
分布式架构中的问题, （如注册发现、跟踪治理、负载均衡、故障隔离、认证授权、伸缩扩展、传输通信、事务处理等问题），如果不局限与采用软件的方式，几乎有对应的硬件解决方式：
系统伸缩扩容问题（X轴方向扩容，水平扩容）：购买新机器，部署若干副本实例来分担压力；
负载均衡问题：布置负载均衡器，选择恰当的均衡算法来分流；
传输安全问题：布置TLS传输链路，配置好CA证书以保证通信不被窃听篡改；
服务发现问题：设置DNS服务器，让服务访问依赖稳定的记录名，而不是异变的IP地址。
等等。
微服务时代，之所以采用软件的代码层面而不是硬件的基础设施去解决这些分布式问题，主要是因为硬件构成的基础设施跟不上有软件构成的应用服务的灵活性的无奈之举。
如果，软件可以通过键盘命令变出相应的应用服务器，负载均衡器，DNS服务器、网络链路这些设施呢？
微服务时代本身的常见离不开以Docker为代表的早期容器化技术的巨大贡献。
虚拟化技术和容器化技术：
早期：
软件定义网络（Software-Defined Networking，SDN）
软件定义存储（Software-Defined Storage，SDS）
Docker Swarm（2013）Apache Mesos（2012）
普遍被认可：始于2017年 Kubernets（K8S）取得容器战争胜利
2017年：
Docker竞争对手RKT容器一派的领导者CoreOS放弃自己的容器管理系统Fleet，在未来所有的功能迁移到K8S上实现
容器管理领域独角兽Rancher Labs 宣布放弃内置数年的容器管理系统Cattle，提出“All-in-Kubernetes”战略。1.X版本支持多中容器系统的管理工具Rancher，2.0开始完全绑定Kubernetes。
Kubernetes的主要竞争者Apache Mesos在9月正式宣布了“Kubernetes on Mesos”集成计划。
Kubernetes的最大竞争者Docker Swarm的母公司Docker，10月份被迫宣布Docker宣布支持K8s容器管理系统。
基于容器管理，可能会容易导致精细化缺失，力度粗犷，只能到容器化层面，对远程服务很难游戏管控。类似的，在服务监控，认证，授权，安全，负载均衡等方面都有可能面临细化管理的需求。eg：服务调用是的负载均衡，往往需要根据流量特征，调整负载均衡的层次、算法等，而DNS虽然能实现一定程度负载均衡，但通常并不能满足这些额外的需求。
为了解决上面的问题，虚拟化的基础设施很快完成第二次进化，引入了今天被称为“服务网格（Service Mesh）的边车代理模式（Sidecar Proxy）”
在虚拟化场景中的边车指的是有系统自动在服务容器（通常是指Kubernetes的Pod）中注入一个通信代理服务器，以类似网络安全里的中间人攻击的方式进行流量劫持，
在应用毫无感知的情况下，悄然接管来自控制器的指令（称为控制平面通信），
根据控制平面中的配置，对数据平面通信的内容进行分析处理，
以实现熔断、认证、度量、监控、负载均衡等各种附加功能。
通过边车代理模式，实现了既不需要在应用层面加入额外的处理diam，也提供了几乎不亚于程序代码的景象管理能力。
服务网格2018年才火起来，目前是新潮的概念，未完全成熟，甚至连K8s也是新生事物。
Istio is a Service Mesh that manages communications between microservices.
Docker & Kubernetes : Istio (service mesh) sidecar proxy on GCP Kubernetes - 2020
Docker
Kubernetes（k8s）
服务网格（Service Mesh）的边车代理模式（Sidecar Proxy）
无服务时代：
2012年 Iron.io公司率先提出 无服务（Serverless）
2014年 亚马逊发布了Lambda商业化无服务计算平台
2018年 阿里云、腾讯云等厂商也开始跟进，发布了旗下的无服务产品。
云计算时代新的事物。
无服务应该翻译无服务器（Serverless）更为合适。
目前还不太成熟。
或许未来会发展称为未来云计算的主要形式。
无服务涉及两块内容：
- 后端设施（Backend）：数据库、消息队列、日志、存储等运行与云中。
- 函数（Function）：业务逻辑代码，运行在云端不必考虑算力，不必考虑容量规划。（计费可能算个问题）。函数即服务（Function as a Service， FaaS）
目前问题：
冷启动慢，数十到数百毫秒，甚至秒级启动。
目前无服务架构，确实可以降低一些应用的开发和运维环节的成本，
eg：优势适合的地方：不需要交互的离线大规模计算，多数Web咨询类网站、小程序、公共API服务、移动应用服务端等都契合于无服务架构锁擅长的短连接、无状态、时候事件驱动的交互形式。
可能不太适合的地方：信息要求较高、需要长链接等特征的应用，无服务的“无限算力”的假设据定了它必须按使用量（函数运算的时间和占用内存）计费以控制消耗的算力的规模，因而函数不会一直以活动的状态常驻服务器，请求到了才会开始运行，这就导致了函数不便依赖服务端的状态，也导致函数有冷启动时间，响应的性能可能不太好。目前无服务冷启动的过程大概是数十到数百毫秒级别，对于Java这类启动性能差的应用，甚至接近秒的级别。
软件开发的最大挑战就在于只能在不完备的信息下决定当前要处理的问题。
尽管目光所及之处，只是不远的前方，即使如此，依然可以看到那里有许多值得去完成的工作在等待我们。
----Alan Turing，Computing Machinery and Intelligence, 1950
参考：
Computer Network Architecture - javatpoint
AFS - Andrew file system | PadaKuu.com
https://en.wikipedia.org/wiki/Kerberos_%28protocol%29
3. Microkernel Architecture - Software Architecture Patterns [Book]
Kubernetes Components | Kubernetes
Docker & Kubernetes : Istio (service mesh) sidecar proxy on GCP Kubernetes - 2020
1173
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
