我已经阅读了很多关于微服务的内容,并希望用这种方法构建我的应用程序.到目前为止我所知道的是我有一些服务,比如:
负载均衡器 - 处理每个请求,并将其推送到其他服务
授权服务 - 授权我的用户
数据库 - 用于我的微服务.我想为每个服务使用一个具有不同模式的DB实例.
服务A - 用于功能A.
服务B - 用于功能B.
等等
我发现,Heroku是部署应用程序的有趣场所.我的问题是我完全不理解他们的意识形态.到目前为止我所做的是创建/注册几个"应用程序":
我-APP-AUTH
我的应用程序内的负载均衡
等等
我知道,Heroku为每个应用程序提供了一些公共主机名,这就是我的担忧开始的地方.我应该使用公共主机名部署我的内部服务吗?我不这么认为.在这里,我的问题来了:
任何人都可以提供一些指导,如何处理Heroku上的微服务?我应该如何部署它们?我应该如何定义负载均衡器,并将内部服务挂钩?什么是JHipster?我需要它吗?我怎么用呢?我应该使用Heroku工具(例如CLI)还是可以使用我的gitlab repo?关于那个,我在互联网上找不到任何关注点.
Heroku是一个非常简单的平台即服务公司.Heroku的工作方式非常简单:
您在Git repos中有多个项目(服务).
您为每个项目(每个Git仓库)创建一个Heroku应用程序.
然后,您将代码从每个Git仓库推送到各自的Heroku应用程序.
Heroku会为您拥有的每个应用分配一个公共URL.
如果您的每个服务现在都在Heroku上运行,他们可以通过公共HTTP向对方发送API请求.
现在 - 关于Heroku上关于面向服务架构的问题.
如果您在Heroku上进行SOA,则需要让每个服务通过HTTPS公开对话.这是典型的"模式".
因为Heroku为每个应用程序提供免费的SSL,并且每个应用程序都位于同一个Amazon区域 - 通过HTTPs在您的服务之间进行第四和第四次交谈是非常快速和安全的.
每个Heroku应用程序都具有自动负载平衡功能,因此无需担心负载均衡器.
这里的下一个选项(如果您不想遵循典型模式)是使用RabbitMQ或Amazon SQS(排队服务)之类的东西,并在您的不同服务之间共享"消息".
在这种模式中,每个服务仍然会有一个Heroku应用程序,但不是通过HTTP相互通信,而是通过像Rabbit或SQS这样的排队协议与其他服务进行通信.这有一些速度优势.
关于身份验证服务,您可以使用多个提供程序来提供此功能.我所知道的最受欢迎的是Stormpath.如果您浏览Heroku插件市场,您也可以找到其他人.
最后,对于数据库内容:您可以使用所需的任何数据库提供程序.最受欢迎的可能是Heroku Postgres.它是PostgreSQL的托管版本,非常可靠/易于使用.
您可以在所有服务中共享一个数据库,也可以为每个服务分配一个数据库.这两种策略都可行.