Fix some typos (#481)

Signed-off-by: Xiaoguang Sun <sunxiaoguang@gmail.com>

Signed-off-by: Xiaoguang Sun <sunxiaoguang@gmail.com>
pull/482/head
Xiaoguang Sun 2022-09-16 11:51:27 +08:00 committed by GitHub
parent dea942163c
commit 95dd240adf
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 5 additions and 5 deletions

View File

@ -2,7 +2,7 @@
> No silver bullet. - The Mythical Man-Month > No silver bullet. - The Mythical Man-Month
许多年前我们开发的软件还是C/S客户端/服务器和MVC模型-图-控制器的形式再后来有了SOA最近几年又出现了微服务架构更新一点的有Cloud Native云原生应用企业应用从单体架构到服务化再到更细粒度的微服务化应用开发之初就是为了应对互联网的特有的高并发、不间断的特性需要很高的性能和可扩展性人们对软件开发的追求孜孜不倦希望力求在软件开发的复杂度和效率之间达到一个平衡。但可惜的是NO SILVER BULLET几十年前1975年Fred Brooks就在The Mythical Man-Month中就写到了这句话。那么Serverlss会是那颗银弹吗 许多年前我们开发的软件还是C/S客户端/服务器和MVC模型-图-控制器的形式再后来有了SOA最近几年又出现了微服务架构更新一点的有Cloud Native云原生应用企业应用从单体架构到服务化再到更细粒度的微服务化应用开发之初就是为了应对互联网的特有的高并发、不间断的特性需要很高的性能和可扩展性人们对软件开发的追求孜孜不倦希望力求在软件开发的复杂度和效率之间达到一个平衡。但可惜的是NO SILVER BULLET几十年前1975年Fred Brooks就在The Mythical Man-Month中就写到了这句话。那么Serverless会是那颗银弹吗
云改变了我们对操作系统的认知,原来一个系统的计算资源、存储和网络是可以分离配置的,而且还可以弹性扩展,但是长久以来,我们在开发应用时始终没有摆脱的服务器的束缚(或者说认知),应用必须运行在不论是实体还是虚拟的服务器上,必须经过部署、配置、初始化才可以运行,还需要对服务器和应用进行监控和管理,还需要保证数据的安全性,这些云能够帮我们简化吗?**让我们只要关注自己代码的逻辑就好了,其它的东西让云帮我实现就好了。** 云改变了我们对操作系统的认知,原来一个系统的计算资源、存储和网络是可以分离配置的,而且还可以弹性扩展,但是长久以来,我们在开发应用时始终没有摆脱的服务器的束缚(或者说认知),应用必须运行在不论是实体还是虚拟的服务器上,必须经过部署、配置、初始化才可以运行,还需要对服务器和应用进行监控和管理,还需要保证数据的安全性,这些云能够帮我们简化吗?**让我们只要关注自己代码的逻辑就好了,其它的东西让云帮我实现就好了。**
@ -100,7 +100,7 @@ FaaSFunctions as a Service函数即服务FaaS是无服务器计算的
两者都为我们的计算资源提供了弹性的保障BaaS其实依然是服务外包而FaaS使我们更加关注应用程序的逻辑两者使我们不需要关注应用程序所在的服务器但实际上服务器依然是客观存在的。 两者都为我们的计算资源提供了弹性的保障BaaS其实依然是服务外包而FaaS使我们更加关注应用程序的逻辑两者使我们不需要关注应用程序所在的服务器但实际上服务器依然是客观存在的。
当我们将应用程序迁移到容器和虚拟机中时其实对于应用程序本身的体系结构并没有多少改变只不过有些流程和规定需要遵守比如12因素应用守则但是serverlss对应用程序的体系结构来说就是一次颠覆了通常我们需要考虑事件驱动模型更加细化的不熟形式以及在FaaS组件之外保持状态的需求。 当我们将应用程序迁移到容器和虚拟机中时其实对于应用程序本身的体系结构并没有多少改变只不过有些流程和规定需要遵守比如12因素应用守则但是serverless对应用程序的体系结构来说就是一次颠覆了通常我们需要考虑事件驱动模型更加细化的部署形式以及在FaaS组件之外保持状态的需求。
## Serverless 的使用场景 ## Serverless 的使用场景
@ -176,7 +176,7 @@ Serverless架构明显比其他架构更简单。更少的组件就意味着
**降低人力成本** **降低人力成本**
不需要再自己维护服务器操心服务器的各种性能指标和资源利用率而是关心应用程序本身的状态和逻辑。而且serverless应用本身的部署也十分容易我们只要上传基本的代码但愿例如Javascript或Python的源代码的zip文件以及基于JVM的语言的纯JAR文件。不需使用Puppet、Chef、Ansible或Docker来进行配置管理降低了运维成本。同时对于运维来说也不再需要监控那些更底层的如磁盘使用量、CPU使用率等底层和长期的指标信息而是监控应用程序本身的度量这将更加直观和有效。 不需要再自己维护服务器操心服务器的各种性能指标和资源利用率而是关心应用程序本身的状态和逻辑。而且serverless应用本身的部署也十分容易我们只要上传基本的代码单元例如Javascript或Python的源代码的zip文件以及基于JVM的语言的纯JAR文件。不需使用Puppet、Chef、Ansible或Docker来进行配置管理降低了运维成本。同时对于运维来说也不再需要监控那些更底层的如磁盘使用量、CPU使用率等底层和长期的指标信息而是监控应用程序本身的度量这将更加直观和有效。
在此看来有人可能会提出“NoOps”的说法其实这是不存在的只要有应用存在的一天就会有Ops只是人员的角色会有所转变部署将变得更加自动化监控将更加面向应用程序本身更底层的运维依然需要专业的人员去做。 在此看来有人可能会提出“NoOps”的说法其实这是不存在的只要有应用存在的一天就会有Ops只是人员的角色会有所转变部署将变得更加自动化监控将更加面向应用程序本身更底层的运维依然需要专业的人员去做。
@ -194,7 +194,7 @@ Serverless架构明显比其他架构更简单。更少的组件就意味着
以AWS Lamba为例当平台接收到第一个触发函数的事件时它将启动一个容器来运行你的代码。如果此时收到了新的事件而第一个容器仍在处理上一个事件平台将启动第二个代码实例来处理第二个事件。AWS lambad的这种自动的零管理水平缩放将持续到有足够的代码实例来处理所有的工作负载。 以AWS Lamba为例当平台接收到第一个触发函数的事件时它将启动一个容器来运行你的代码。如果此时收到了新的事件而第一个容器仍在处理上一个事件平台将启动第二个代码实例来处理第二个事件。AWS lambad的这种自动的零管理水平缩放将持续到有足够的代码实例来处理所有的工作负载。
但是AWS仍然只会向您收取代码的执行时间无论它需要启动多少个容器实例要满足你的负载请求。例如假设所有事件的总执行时间是相同的在一个容器中按顺序调用Lambda 100次与在100个不同容器中同时调用100次Lambda的成本是 一样的。当然AWS Lambada也不会无限制的扩展实例个数如果有人对你发起了DDos攻击怎么办那么不就会产生高昂的成本吗AWS是有默认限制的默认执行Lambada函数最大并发数是1000。 但是AWS仍然只会向您收取代码的执行时间无论它需要启动多少个容器实例要满足你的负载请求。例如假设所有事件的总执行时间是相同的在一个容器中按顺序调用Lambda 100次与在100个不同容器中同时调用100次Lambda的成本是 一样的。当然AWS Lambda也不会无限制的扩展实例个数如果有人对你发起了DDos攻击怎么办那么不就会产生高昂的成本吗AWS是有默认限制的默认执行Lambada函数最大并发数是1000。
**缩短创新周期** **缩短创新周期**