Fix some typos (#481)
Signed-off-by: Xiaoguang Sun <sunxiaoguang@gmail.com> Signed-off-by: Xiaoguang Sun <sunxiaoguang@gmail.com>pull/482/head
parent
dea942163c
commit
95dd240adf
|
@ -2,7 +2,7 @@
|
|||
|
||||
> 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 @@ FaaS(Functions as a Service)函数即服务,FaaS是无服务器计算的
|
|||
|
||||
两者都为我们的计算资源提供了弹性的保障,BaaS其实依然是服务外包,而FaaS使我们更加关注应用程序的逻辑,两者使我们不需要关注应用程序所在的服务器,但实际上服务器依然是客观存在的。
|
||||
|
||||
当我们将应用程序迁移到容器和虚拟机中时,其实对于应用程序本身的体系结构并没有多少改变,只不过有些流程和规定需要遵守,比如12因素应用守则,但是serverlss对应用程序的体系结构来说就是一次颠覆了,通常我们需要考虑事件驱动模型,更加细化的不熟形式,以及在FaaS组件之外保持状态的需求。
|
||||
当我们将应用程序迁移到容器和虚拟机中时,其实对于应用程序本身的体系结构并没有多少改变,只不过有些流程和规定需要遵守,比如12因素应用守则,但是serverless对应用程序的体系结构来说就是一次颠覆了,通常我们需要考虑事件驱动模型,更加细化的部署形式,以及在FaaS组件之外保持状态的需求。
|
||||
|
||||
## 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,只是人员的角色会有所转变,部署将变得更加自动化,监控将更加面向应用程序本身,更底层的运维依然需要专业的人员去做。
|
||||
|
||||
|
@ -194,7 +194,7 @@ Serverless架构明显比其他架构更简单。更少的组件,就意味着
|
|||
|
||||
以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。
|
||||
|
||||
**缩短创新周期**
|
||||
|
||||
|
|
Loading…
Reference in New Issue