网站推广服务包括哪些,wordpress建站案例视频,关键词seo优化公司,百度联盟怎么看广告赚钱【squids.cn】 全网zui低价RDS#xff0c;免费的迁移工具DBMotion、数据库备份工具DBTwin、SQL开发工具等
如果您一直在开发或以某种方式参与应用程序架构#xff0c;那么在过去的几年中您肯定看到了许多变化。有很多不同类型的架构和技术陆续出现然后消失#xff0c;以至于…【squids.cn】 全网zui低价RDS免费的迁移工具DBMotion、数据库备份工具DBTwin、SQL开发工具等
如果您一直在开发或以某种方式参与应用程序架构那么在过去的几年中您肯定看到了许多变化。有很多不同类型的架构和技术陆续出现然后消失以至于有时很难跟踪它们。但是当你反思它们时它们不仅可以讲述过去的故事还可以预示应用程序架构的发展方向。
在这篇文章中我将讨论近几年来应用程序架构在我看来是如何演变的以及每次演变的驱动因素是什么。我们将讨论单体架构、面向服务的架构(SOA)、微服务最后是事件驱动架构(EDA)。让我们开始吧
单体架构
在过去所有东西都是单体的。大团队会专注于一个单体应用程序这个应用程序负责执行许多任务。单体架构允许您迅速地将原型组合在一个应用程序中这个应用程序可以完成所有的事情。由于你不需要依赖其他团队所以维护成本较低。然而当应用程序被推送到生产并继续增长时事情很快就会失控。
例如一个典型的单体应用程序可能包括多个层次如用户界面层、业务逻辑层、数据接口层和数据存储层。此应用程序会接受用户输入处理它应用业务逻辑使用现有数据进行丰富然后可能将其存储在关系型数据库中供以后进行额外的处理。
单体架构有三个主要的缺点部署慢、可扩展性差和相互依赖。单体应用程序更难调试和更新。大型应用程序需要大量的时间和努力来确定问题并部署更新而当这些更新被推出时需求可能已经发生了变化。
单体应用的第二个缺点是可扩展性差。一个应用程序能做的只有那么多。在当今的世界计算资源比过去便宜得多我们通过简单地为应用程序投入更多的计算资源更容易地并行计算。一个过去运行在强大但非常昂贵的服务器上的单体应用程序现在可以作为较小的应用程序并行运行在普通硬件上。此外较慢的部署我们之前讨论过的使得快速扩展变得更加困难。
此外在一个大型应用中每一个小的改动都可能影响到应用的一个或多个其他部分。这增加了可能破坏重要功能的额外风险。例如用户界面层的一个错误可能会影响整个应用程序。
在我之前的工作中我曾在一个应用上工作该应用提供了对跨资产市场数据股票、外汇、大宗商品等的访问。在一个版本中我为股票用户推出了一个新功能但由于我们的应用是单体的我的这个小改动最终破坏了一个由外汇用户使用的应用的非常重要的功能。这两个功能是完全独立的但由于它们是同一个代码库的一部分它们有很多共享资源。不用说外汇用户并不满意。
敏捷 vs. 瀑布
很快公司们开始意识到他们需要找到一个更好的方法来构建他们的应用程序。大约在同一时间敏捷方法论正变得越来越受欢迎。以前公司主要使用瀑布方法论来开发应用程序这意味着收集大量的需求进行极端的规划涵盖所有的边界情况然后在一个大的爆炸中小心地发布具有所有功能的最终产品。 对于某些行业由于每次迭代所涉及的成本和/或监管要求这是唯一的方法。而对于许多其他行业敏捷方法论更为有效。敏捷方法论是关于在快速迭代中发布最小可行产品(MVP)。你失败得越快知道什么不起作用就越好。敏捷方法论虽然已经存在了一段时间但在2011年左右变得非常流行当时敏捷联盟是的这是真的创建了《敏捷实践指南》。敏捷认证和敏捷教练无处不在。不管你怎么努力躲藏你的敏捷教练总会在每日晨会时找到你。
面向服务的架构
随着敏捷方法论的推广人们明确地认识到拥有可以轻松更新和扩展的小型应用程序有着宝贵的优势。这引出了面向服务的架构。在单体架构中一个应用程序自己做所有事情而在面向服务的架构中一个应用程序会被分解成基于其用途的几个较小的服务。正如IBM的这篇文章所提及的 SOA的核心目的是通过格式良好、易于使用、同步的接口如Web服务来暴露系统中的数据和功能。 回到我们关于单体应用的例子它可以被分解成多个较小的服务 用户界面服务。 业务逻辑服务。 数据集成服务。 数据存储服务。
每个服务都负责一个特定的用例。它们都独立存在并通过基于简单对象访问协议(SOAP)的同步API进行通信。然而随着你组织中服务数量的增长为每个服务编写一个与其他所有服务通信的接口会变得越来越困难。这时你会从企业服务总线ESB中受益。ESBs允许开发人员解耦他们的服务请参阅下面的图并使整体架构更加灵活。 解耦服务图
解耦您的服务
面向服务架构的多个好处包括 快速推出。 更容易调试。 可扩展性。 职责明确。 对其他服务/组件的依赖性较少。
由于这些明显的优势大多数公司开始采纳面向服务的架构以及敏捷方法论但他们几乎不知道云计算的革命即将到来。
微服务
面向服务的架构最终为微服务架构铺平了道路它们有很多相似之处但在一些细微之处有所不同。
我认为导致微服务架构产生的最重要因素是廉价和灵活的基础设施。由于水平扩展你的基础设施并在集群上而不是在强大的服务器上运行你的服务变得如此容易所以鼓励开发人员编写可以轻松在集群上并行运行的软件。大约在同一时期出现了大量的分布式应用和框架如Hadoop它普及了map-reduce编程模型。
此外大约在2015年AWS变得非常流行。那时AWS已经存在了一段时间但大约在2015年基础设施即服务(IaaS)的整个概念真正起飞而且非常方便地启动EC2实例变得很便宜。初创公司是第一个采用IaaS的不久之后被中小型公司所追随。经过大量的争论和讨论大型公司最终接受了IaaS并决定采用混合云方法。 分布式云基础设施是很好的但有一个问题。与你自己的数据中心中的少量服务器相比它非常难以预测和管理。在分布式云基础设施上稳健地运行一个应用程序绝非易事。很多事情可能会出错。你的应用程序的一个实例或你的集群上的一个节点可能会静默地失败。你如何确保你的应用程序可以继续运行尽管出现这些故障答案是微服务。
微服务是一个非常小的应用程序负责一个特定的用例就像在面向服务的架构中一样但它与其他服务完全独立。它可以使用任何语言和框架开发并可以部署在任何环境中无论是本地还是公共云。此外它们可以轻松地在不同地区的多个不同服务器上并行运行以提供并行性和高可用性。例如一个小的数据应用程序可以在一个计算集群的5个实例上运行这样如果一个实例失败其他4个会确保你的数据应用程序继续运行。
将你的服务分解为多个微服务意味着它们需要相互通信。与依赖企业服务总线和同步API的面向服务架构不同微服务利用了消息代理和异步API。
容器化
正如面向服务架构的转变受到敏捷方法论的推动一样微服务运动也受到了容器化的推动。HackerNoon的这篇文章很好地描述了容器化 容器化涉及将一个应用程序及其所有相关的配置文件、库和依赖性捆绑在一起使其能够在不同的计算环境中高效且无错误地运行。 Docker最初于2013年发布是最受欢迎的容器平台。如今几乎所有现代软件都可以通过docker来运行。随着云基础设施的兴起确保在新环境中、特别是在云上运行软件docker变得极其重要。
随着微服务的普及服务网格的概念也随之兴起该网格允许服务主要使用请求/应答消息模式保持连接。Nginx在其博客上对服务网格有很好的解释 服务网格是一个可配置的、低延迟的基础设施层设计用于处理使用应用程序编程接口(API)的应用程序基础设施服务之间基于网络的大量进程间通信。 在2014年Google开源了Kubernetes允许你编排你的微服务。借助docker和Kubernetes部署和管理云上的分布式微服务变得容易得多。在过去的几年中这两种技术变得越来越受欢迎。如今大多数新兴的初创公司都编写原生云微服务可以通过docker轻松部署并通过Kubernetes编排许多大型公司正在与Pivotal这样的公司合作轻松地将他们的应用迁移到云上。
云基础设施和分布式微服务的兴起导致了大量为监控微服务它们消耗了多少内存、自动化自动跨服务器持续部署微服务和资源管理为最便宜的AWS资源竞标提供服务的初创公司的诞生。如果你曾参加过AWS峰会那么你就知道我在说什么。
事件驱动的架构
随着我们继续捕获越来越多的数据我们继续找到创造性的方法来使用它。随着IoT如Alexa微波炉和可穿戴设备如Apple Watch的兴起有了大量的时序数据或事件。
在我们面前有这么多的屏幕智能手机、智能手表、平板电脑、笔记本电脑等可以立即推送通知公司发现变得更加事件驱动非常重要。他们的用户期望在重要事件发生时获得实时通知。例如当我的Delta航空公司应用程序通知我航班延误或开始登机时它都是实时的。它不等我手动检查或仅在固定间隔时检查事件。 在这个勇敢的新事件驱动的世界中微服务是围绕事件设计的。它仍然相对较新并正在迅速地在各个行业中普及。 结论
在这篇文章中我的目标是向您展示在我看来应用程序架构在过去几年中如何受到不同技术和需求的影响和发展。当大多数公司尝试采用微服务和云时其他公司则走在前面并采用了事件驱动的架构。在我看来可预见的未来是以事件驱动的方式设计的微服务。 作者Himanshu Gupta
更多内容请关注公号【云原生数据库】
squids.cn云数据库RDS迁移工具DBMotion云备份DBTwin等数据库生态工具。
