查看原文
其他

Kubernetes取代Linux、Apache;Go取代Python;Etcd或取代MySQL

2017-07-27 云头条

作者简介:Sirish Raghuram是提供托管私有云部署方案的Platform9公司的首席执行官。


云头条摘要:“KEG”架构会取代LAMP架构吗?



多年来,LAMP架构(Linux、Apache、MySQL和PHP/Python/Perl)一直是许多开发人员心目中的绿洲,他们想构建现代应用程序,又不想深陷于某些大厂商的生态系统这片沙漠。LAMP是一种很方便、广泛使用的开源框架;有了它,开发人员很容易构建应用程序架构。


然而,正如上世纪90年代后期迅速变化的技术格局为LAMP架构的崛起创造了条件,如今Web开发领域的新变化和新趋势导致LAMP架构迎来了所谓的“日落时期”(sunset period)。


今天,如果你不将应用程序分解成可以独立部署和扩展,具有应对故障的灵活性和弹性的小型组件,实际上死路一条。两大趋势彰显了这个转变:首先,LAMP架构的每一层现在“作为一项服务”来提供,让开发人员能够将许多职责外包出去,并且最终更快地交付更好的产品。


其次,近些年来移动使用模式的兴起使得这种重组加快了步伐。移动技术现在是用户与应用程序连接的主要方式。这意味着开发人员必须构建这样的应用程序:具有高度弹性,在全球范围内可用,具有极高的扩展性,足以处理数百万个客户。无论你怎么来搞,LAMP架构都根本无法满足这些要求。


那么,下一步该何去何从?从开发框架、编程语言到介于之间的一切,如今开发人员拥有比以往任何时候都要多的选择,这只工具箱只会越来越庞大。因此,开发人员期望我们一直称为LAMP的架构的各个部分能够不断发展。下面简单描述一下如果我们用更现代的工具和框架来重新塑造LAMP架构,新的LAMP架构应该会是什么样:


Kubernetes同时取代Linux和Apache


传统上,设计应用程序时着眼于某种特定的操作系统。对于LAMP架构而言,这意味着Linux。而如今,新的思路青睐Linux无力提供的更出色的可移植性。这使得Kubernetes这种开源容器编排引擎成为取代Linux的一种很好的替代平台。Kubernetes将Linux抽取出来的能力让它成为如今许多应用程序的记录操作系统。


一个额外的好处是,Kubernetes还擅长路由网络流量,这意味着它也可以取代Apache。多亏有了Kubernetes,需要变更时,开发人员再也不需要处理配置文件和静态配置了。使用诸如Ingress、Services和LoadBalancer之类的Kubernetes构件来路由网络请求,开发人员可以随意采用一种更分布式、更有弹性的方法,这种方法又具有很强的动态性和适应性。


Etcd或许取代替换MySQL


MySQL仍然是一种颇受欢迎的关系数据库管理工具。然而,如果你想要又有弹性的持久性数据,那么需要将它存储在某个地方,这个地方自然允许横向扩展,还可以透明地处理节点故障。换句话说,你想要分布数据层以便能够支持这种属性,MySQL可能不是最佳选择。


如今外头有好多服务可以满足这个要求,最受欢迎的服务之一就是Etcd。其他服务还包括Consul(来自HashiCorp)、doozerd、CockroachDB以及谷歌的Spanner。最后,合适的选择归结为应用程序的性质。


CockroachBD和Spanner最适合这种应用程序:需要一种更高级的数据管理系统来存储数量更庞大的数据,满足传统的ACID数据库保证,并使用像SQL这样的传统查询语言。对于其余大多数应用程序来说,Etcd、Consul和DoozerD都可以胜任。


除了提供数据持久性的服务外,应用程序还越来越依赖附加的数据处理服务,比如消息队列服务。这些服务还需要具有很高的扩展性和可靠性,以便满足应用程序的要求。


Go取代Python


Go语言正在蚕食Python的地盘,成为开发现代应用程序(尤其是微服务)的首选语言。


相比Python,Go具有的一个关键优势是,所有依赖项在构建时得到了解决。这帮助开发人员消除了代码中隐藏的任何意外问题,并保证应用程序在部署后不会突然崩溃。


最重要的是,Go还允许应用程序可以充分发挥多个CPU核心的功能。基本上来说,如今CPU没有变得更快多少,这意味着获得更高速度的最好办法就是添加更多的CPU核心。Go在这方面也具有优势:它轻松支持并发机制,因而开发人员很容易充分发挥多个核心的功能。由于Go程序是静态类型,并编译成原生机器代码,所以运行起来比解释语言或动态编译语言(比如Python)要快得多。


综上所述,可以说“KEG”架构是取代LAMP架构的上佳选择。不过这忽视了更重要的一点:无论喜不喜欢,标准“架构”的整个概念都在瓦解。


如今,开发人员可以使用比过去更庞大、更丰富和更强大的一系列工具,这意味着遵循像LAMP或者甚至KEG这样的规定性方法不是正确的出路。在这个新世界,关键是搞清楚应用程序背后的行为、模式和原则。之后,什么样的工具适合处理任务才会一目了然。


云头条编译、未经授权谢绝转载


欢迎加入交流,群主微信:aclood,注明公司名称和职位


您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存