在Heroku上探索微服务架构

如果您有能力承担适当地增加前期投资,那么使用微服务架构构建应用程序是一个很好的长期决策。 Heroku提供了大多数开发人员都知道的用于简单部署的平台,但是它也大大简化了微服务架构。

您所说的这些“微服务”是什么?

如果您在微服务一词出现之前就已经从事Web开发,那么您将其称为面向服务的体系结构(SOA) 。 最大的不同是,SOA通常与基于WSDL / SOAP / XML的Web服务相关联,这些Web服务被通用功能,团队和数据访问所隔离,而微服务的通用基调则更加深入。 微服务还专注于通过功能隔离应用程序,但更多地围绕云部署,连续交付,扩展,敏捷开发和减少相互依赖性而进行。

开发Web应用程序时,通常有两种解决方法: Monolith或Microservice

从一开始,整体式组件的构建就变得非常容易和快捷。 您可以在单个IDE中管理整个应用程序。 您所有的数据都保存在一个数据库中。 您可以对各种不同的零件进行交叉查询以组装报告。 您可以通过将相互依赖的插入/更新包装到单个事务中来确保数据完整性,如果发生故障,这些事务可以回滚。 您的控制器可以轻松地从不同的相关模型中提取数据,而无需创建API。 这种类型的开发绝对导致能够非常快地获得大量功能。

“从一开始,Monolith的构建就变得非常容易和快捷。” 通过@codeship

点击鸣叫

微服务致力于获取功能集并将其简化为许多较小的应用程序。 较小的测试套件,较小的库依赖项,较小的托管要求,较小的代码库,较小的文档,较小的学习曲线以及易于缩放的单个部分。 不利之处在于,您必须开发方法以使各部分之间通常通过REST API或共享队列相互通信,这会花费更多时间。 此外,您还必须考虑托管每个服务。

Monolith与微服务的权衡

让我们看看选择微服务或整体架构方法时会遇到的一些折衷。

依赖互锁

独石的第一个也是最明显的问题是依赖锁。 遵循能够为自己的功能指定其他gem依赖项的模式的Ruby gem和其他库最终会产生交叉兼容性问题。

在开发功能时,只需将gem添加到Gemfile中,进行快速捆绑安装 ,就可以了。 随着时间的流逝,您将意识到其中一些gem具有相同的gem依赖关系,并在此具有特定的版本。 当您想升级一个以获得新功能或改进时,您会发现您不能这样做,因为其他未由其作者频繁更新的库将具有其主干库之一的不兼容版本。 没有另一个您就无法升级。 从小功能一直到语言版本和框架。

在微服务架构中,由于部件将被分为不同的库依赖集,因此不太可能发生该问题。 有冲突的库有可能甚至不在同一服务中,但是即使它们冲突,它们也可以将影响范围减小到应用程序的很小一部分,而不是阻塞整个系统。 通过重写没有依赖关系的系统部分,完全杀死它或用一种更适合其功能的语言替换它,可以使在应用程序上实施水牛理论变得更加简单。 从使用Go进行并发到使用R进行数据分析,这可能意味着任何事情,但是当要更换的零件较小时,整个过程将得到简化。

现在可以争论的是,通过为特定功能部件创建新服务并让整体结构代替原始结构使用整体结构,可以完成完全相同的操作。 如果您有一种简单的方法可以验证使用依赖项的地方,使用替换代码的每个地方以及通过删除这些部分并将其替换为服务不会影响其他逻辑,则该方法非常好。

以我的经验,在编写新服务之前验证所有这些内容,然后潜在地将数据迁移到新服务要比听起来困难得多,而且已经听起来很困难。

举办挑战

第一次提交时,部署和托管您的整体组件从未如此复杂。 随着它的增长,增长和增长,部署需要更长的时间,服务器RAM需求增加,引导时间增加,数据库大小增加。 那是在我们考虑流量本身增加之前。

即使只是一小部分应用程序看到流量,突发时间段或服务器压力突然增加……也会影响到整个过程。 要扩展它,您必须按照我们到目前为止一直在努力的大规模服务器需求来扩展整个过程。 是否想创建一个新的子域来定向某些类型的调用,例如API调用,以便您至少可以隔离压力最大的流量? 仍然必须为此维护大型服务器,现在您有了额外的负载平衡器,同时将冗余/容量减少了一半,以便可以实现隔离。

微服务托管的复杂性往往会因所涉及的语言而异。 如果一切都使用Java完成,那么类似JBoss App Server的应用程序可以将多个独立的应用程序部署为整个集群中的容器,彼此通信,分配负载,甚至分配后台作业。 与这种类型的设置有关的时间投资和复杂性会产生基础结构级别的依赖性和投资偏差。 那是因为升级某些服务的内容可能意味着投资整个新集群。 但是在大多数情况下,由于向后兼容,Java世界使这一点变得更加容易。 造成这种情况的原因有很多,它们都希望在JVM上运行并访问这些基础结构工具,而无需使用Java本身进行开发,这是最大的原因之一。

使用Go或Node.js,通常只需要启动即可,因为服务器是该语言的一部分。

使用PHP或Perl,只要您使用的是该语言的相同版本,就很容易在同一服务器上部署数百个服务。 但是,管理资源以独立扩展资源更加复杂。

使用Ruby,除非您利用Torquebox之类的东西通过jRuby获得JBoss App Server的好处,否则将多个服务部署到同一服务器会更加复杂且占用大量资源。 否则,在同一个虚拟机或容器上站着多个生产Ruby应用程序可能会对RAM造成相当大的负担。

数据库挑战

关于微服务架构中的数据库,存在两种思想流派。 有人指出,每个服务都应具有自己的隔离数据源。 另一个要求多个微服务共享同一数据库,并允许数据库本身容纳应用程序之间共享的许多逻辑。 这些都不是错误的……仅取决于您所讨论的应用程序的哪些部分,没有理由不能在最适合它们的两个地方都做。

PostgreSQL之类的数据库使数据库能够执行您不知道的数据库可以做的事情,并提供几种不同的语言供您编写内部功能(SQL,Javascript(V8),Python,Perl,R等)。 。 在此之前,您甚至还没有考虑其他服务可以使用的诸如PubEN的LISTEN / NOTIFY之类的工具。 有时,您将获得的数据很少会因相互连接而受益,它们可能具有不同的I / O或缓存需求,并且最好在专用数据源中独立增长。

最重要的是要避免坚持某种类型的意识形态建筑纯洁性,以免为您的问题找到最佳解决方案。 隔离通常在概念上更简单,但是随着您发现自己不断地在服务之间缓存,复制或同步某些数据以减轻压力或加快系统的某些部分而变得更加复杂。

Heroku在所有这一切中从哪里来?

当您设计微服务架构时,这就是您的想法:

简单1

这是实际发生的事情:

现实

Heroku通过将通用理论基础架构和部署逻辑简化为通用实践基础架构和部署逻辑,同时消除了这样做的语言限制,为您简化了很多工作。

这些类型的基础结构问题是您在尝试将创意推向市场时无需关心的事情。 您将专注于系统将要做什么,它将如何去做,如何很好地解决它的技术约束以及您的服务需要互相通信的内容。 您不需要关注的是管理跨多个服务,多个环境,多个部署过程,可变数量的服务器的共享配置变量,是否现在就需要为每个服务使用负载均衡器,管理DNS条目和路由IP会随着实例的变化而变化,或者跨多个服务子域管理和更新安全证书。

负载均衡器

借助Heroku的Dyno(VM)设置,您可以随时动态增加测功,并按使用它们的微观时间单位计费。 为了在网络上做到这一点,您的dynos在负载均衡器后面。 当您增加或减少它们时,Dyno会启动,验证成功,使用负载均衡器签入,然后在关闭时自行注销。

如果要设置自己的实例,则必须在它们前面设置自己的负载平衡器,以为此做准备并使注册和注销过程自动化。 或者直接指向VM,并希望您不需要扩展。

SSL管理

安全证书是那些必要的细节之一,如果您必须自己进行管理,这些细节往往会令人头疼。 您的用户将看到的面向公众的URL(例如您的API和应用程序前端)将绝对要求您拥有自己的证书,支付X年的费用,在需要更换时进行更新,关闭某些类型您所拥有的每台服务器和负载平衡器上基于安全漏洞等进行的加密/握手过程。

在VPC中,将其保留在公共URL后面的风险较小,因为VPC正在加密所有内容。 但是如果没有这些,您就需要整个云基础架构中的SSL。 每个Heroku服务都有一个内部Heroku子域。 该URL具有Heroku的SSL。 您不必为此付出额外的费用,也不必跟上它,监视它的到期期限或计划如此频繁地重新发行它。 如果它不是面向公众的,则只需使用那些Heroku URL即可简化整个内部服务过程。

语言特定功能

多语言微服务架构是Heroku赢得巨大成功的领域。 如果公司使用单一语言进行标准化,则使他们更容易投入时间来开发用于部署,服务器配置,应用程序监视和配置变量的特定于语言的工具。

在许多情况下,配置将仅加载到语言文件或服务器中丢弃的文件中,然后通过XML,JSON或YAML与该语言的库一起解析。 这造成的最大问题是技术投资。 您不仅致力于该语言,而且还致力于使用围绕它的工具,这为无法使用您花时间进行完善的所有工具的其他语言带来了障碍。

Heroku在消除这些投资方面走了很长的路要走。 对于部署,无论使用哪种语言,都非常简单:

git push heroku master

从那里,Heroku接收推送,配置dyno,以每种语言的正确方式加载库,然后启动dyno。 如果存在问题,则不管语言如何,回滚部署都遵循相同的规则。 对于滚动重启,您可以简单地打开预启动功能,使其启动与您所运行的功能相同数量的dynos。 然后,等待它们全部成功启动,换出负载平衡器,然后杀死旧的发电机。

通过Heroku Config工具集中配置 。 它可以集中更新,并自动推送到所有测功机。 无需构建工具即可读取它们,推送文件并通过SSH以特定于语言的重启方式将其来源,无需将其包含在语言文件中作为回购的一部分,也无需在数据库中进行管理并开发逻辑用每种语言来理解它。 就应用程序而言,它们是简单的环境变量,无论使用哪种应用程序语言,它们的设置,读取,编写,更改和发布都可以通过单个命令进行管理。

平台的这些方面减少了您在某种语言上的投资,甚至减少了在垂直扩展的服务器配置(如“企业应用服务器”)中可能遇到的语言版本的限制。 可以轻松地按服务进行升级。 回滚是一致的。 配置是一致的。 部署是一致的。 整体仅具有一套所有内容,因此通常无需担心。 微服务架构必须在每个服务的基础上考虑它们,而Heroku删除了大多数决策。

除去技术投资(除了学习之外),您可以更轻松地为手头的工作选择合适的工具。

  • 利用Rails快速开发功能全面的Web应用程序,其中包含所有外围细节,以平稳地处理HTML和资产。
  • 使用Go可以处理高并发,低I / O工作负载,例如传递电子邮件,发送Webhook或限制并传递API请求。
  • 使用R进行数据分析。
  • 将Java用于某些没有其他语言的库,或者因为您的团队中有一个“用Java来做一切”的人(主要是玩弄)。

你明白了。 通过打开那里所有的技术门,这将成为整个系统的推动者。

日志和监控

不管Linux版本,应用程序语言或运行的服务数量如何,Heroku都会将您的所有服务日志汇总到一个位置。 您可以在运行50个dyno的电子邮件服务上打开日志尾巴,并实时查看每个服务器在一处的位置。 您可以与第三方服务集成,以收集,解析和分析日志,甚至可以设置自己的日志流失以自己处理它们。

Heroku处理实际的dyno监视和响应,因此不必担心。 在运行的应用程序中进行监视的工具仍将是特定于语言的,但是New Relic的免费计划使此操作更加易于管理(Heroku或其他)。

开发/阶段环境

微服务架构中的另一个主要因素是,您必须复制生产设置以用于开发,UAT或登台环境。 Heroku的免费dyno计划使这成为一个琐碎的问题,而不是在虚拟机上复制整个堆栈。 只需创建环境并更改配置即可。

开发人员访问

当您开始构建系统时,团队的访问控制通常不是您最关注的事情。 充其量,您担心要限制对生产环境的访问。 使用Heroku,整个过程变得更加容易,因为您可以将特定的人员添加到特定的项目中。 您可以为他们提供访问应用程序的权限,以执行诸如运行作业之类的事情,而不必向可能暴露更多信息的服务器提供SSH访问权限。

用户数量不花一分钱。 Heroku提供了一个界面,使他们可以管理自己的RSA / DSA密钥和密码,而无需将它们分发给不同的服务器集。 在您希望允许的特定环境中,所有这些“嘿,我可以访问...”请求都变成了几次单击。

总结

Heroku

Docker这样的容器技术在这个领域带来了更多的竞争 ,但是并不是完美的 。 Docker充分表明了Heroku现在已经支持它的承诺,而许多主要的市场参与者正在集中资源以完善该技术的粗糙边缘。 有一天,他们可能像现在的Heroku一样容易,但是时间会证明一切。

单个微服务非常适合连续集成/交付工作流程,因为较小的部分可以更轻松地部署而不会破坏整个系统。 在构建成功完成之后,利用这些流程自动部署到开发/登台/正常运行环境将为您带来另一个绝佳的机会,可以使时间更顺畅

Heroku消除了与微服务架构开发有关的大部分前期投资。 它使得处理几乎无限数量的片段变得相当琐碎,而这正是您以保持理智的方式跟踪微服务所需要的。 如果没有专门的IT员工,使用不止一种语言的微服务会造成很多DevOps问题,Heroku可以缓解绝大多数问题,因此您可以专注于应用程序。

使用Heroku时,这会改变整体与微服务之间的决策公式。 整体而言,在短期内提供的许多优势将与微服务放在一起,这将使长期关注成为更容易的选择。

每个应用程序和业务需求将有所不同。 哪个最适合您的设置? 在微服务或整体架构之间做出决策时,您有什么顾虑?

通过@codeship“探索Heroku上的微服务架构”

点击鸣叫

翻译自: https://www.javacodegeeks.com/2015/07/exploring-microservices-architecture-on-heroku.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值