我正处于从单个单片Web服务到使用Spring Cloud / Spring Cloud Netflix的微服务集合的大型迁移的开始。通过我对微服务的研究，我理解服务之间的划分线应该反映它们之间关注点的分离。影响分离的另一个因素是需要哪些服务单独扩展。
作为一个具体的例子，根据所需的粒度级别，微服务环境最终会像这样：
或者最终可能会出现由他们自己的微服务代表的括号中的每个关注区域，例如：
我认为微服务社区对第二种方法有偏好，我倾向于同意。但是，我遇到的问题是托管和资源限制。
在迁移中，我希望简化资源配置和更新服务的安装。由于我们使用AWS堆栈，Elastic Beanstalk似乎是完美的选择。在研究Elastic Beanstalk的同时，我感到非常沮丧，发现每个帐户限制了25个应用程序。不仅如此，EC2每个区域每个区域限制为20个实例。看起来微服务架构会很快达到这个极限，特别是当你为每个服务添加多个环境（登台和制作）时，更不用说网站和内部工具了。
有了我在网络上看到的有关微服务的所有令人惊叹的内容，我对于缺乏有关微服务实际托管的信息而感到惊讶和有些失望。我错过了什么吗？是否有关于在AWS上部署多个微服务的信息？
据我了解，Netflix使用AWS进行自己的微服务托管，除了从亚马逊请求额外资源并向其投入资金外，还有其他解决方案吗？他们的Asgard工具会帮助解决这个问题（可能是通过处理服务之间的实例共享）还是会导致相同的结果？
答案 0 :(得分：3)
如上述评论中所述，如果您拥有合法用例，AWS将提高您的限制 - 为什么不呢？他们的业务是向您提供服务。
但是既然你已经提出了除了增加这些限制之外的建议，而且由于你处于设计解决方案的早期阶段，你应该考虑将部分微服务架构基于Docker或其他容器/容器（如服务）（我自己的偏好是AWS的容器服务）。根据您的解决方案的性质，即使在20个EC2实例（每个区域）的限制范围内，如果您有足够大的实例运行，您可以在每个分配的20个实例上运行数十个（甚至数百个轻量级）docker镜像 - 因此，在这20个EC2实例上运行的可能是hundres或成千上万个被关闭的微服务。
对于您可能拥有的许多微服务中的每一个使用完整的EC2图像可能最终会比它需要的成本高得多。
您还应该考虑将AWS Lamba用于至少部分微服务架构 - 它也是AWS提供的“超微服务”工具。