基于Docker微服务架构技术栈

借助于跨境打包和代码分发的优势，Docker正在越来越流行。结合微服务架构，Docker有助于开发人员构建更小、模块化的组件，这些组件组合起来构成复杂问题的解决方案。

迁移到微服务架构需要一些前瞻性的规划，以避免系统变得脆弱，最终成为一个分布式的单体系统。从服务设计到部署监控，使用Docker部署微服务架构需要注意一些事情。基于之前发布的一篇帖子（生产环境运行Docker的九个关键决定），我们聊一聊如何在Docker上规划一个成功的微服务架构。

创建新的微服务时，人们可能急于优化部署模型，典型的做法就是将多个服务放到一个容器中运行。但是，当多个占据同一个容器实例，服务也就不能进行独立地伸缩了。

规划技：采取“一个容器、一个服务”的方法，它支持对微服务进行按需扩展，也不会像单体架构应用一样消耗多余的内存和CPU。

正如典型的云原生架构，入口的HTTP请求会被分发到多个endpoint处理。然而，目前大多数基于云服务的负载均衡器只能将请求分发给不同的服务器实例（VM）， 而不能分发到同一个服务器上的多个容器。一个解决方案是：在基于HTTP的微服务实例的前端，安装一个反向代理服务器，这样请求就可以分发给任意数量的容器实例。

我们可能需要比负载均衡更高级的功能，比如身份认证、授权和限速。暴露给移动设备或者开发者的服务需要预防DOS攻击，需要将单一外部URL的请求分发到多个内部的微服务。

规划技巧：安装一个反向代理服务器或API管理平台。目前有很多商业和开源选项，包括：3scale、Apige、Kong，或者定制化的NGINX。

传统云服务提供的是基于网络的块存储设备，而容器需要一个与宿主机隔离的文件系统。一旦该容器被删除，容器内的数据就会丢失。此外，我们不能期望一个容器在同一个宿主机上呆很长时间。因此，将宿主机的存储挂载到容器中，生产环境的数据库肯定不能使用。我们需要一个更好的选择，以保证数据库中的数据很安全，并且数据库运行时有足够的性能保证。

规划技巧：不要在容器中部署数据库。使用Database-as-a-Service（无需管理自己的实例），或者使用自己的数据库解决方案（不使用容器）。唯一不需要挂存储卷的例外是：微服务的只读数据可以在构建容器时，直接打包进去。

为了弹性伸缩和高可用，微服务会分布在不同的Docker宿主机上。将域名或IP硬编码到应用中不是一个明智的选择。相反，你需要管理应用之间的服务发现策略，一个服务可以通过名字来定位另一个服务。Docker只负责管理你的容器实例。

规划技巧：选择一个服务发现策略，当你伸缩容器资源时，服务发现策略能够同步更新。可选的项目有ZooKeeper、Consul、etcd、Eureka，或者内部DNS策略。

大多数web应用程序中， 图像、CSS和JavaScript库都是共享的。如果你使用web框架，例如Ruby on Rails，asset pipeline可以管理这些资源。但是，在生产环境中管理起来比较麻烦。Asset pipline生成的文件不能跨容器共享。这里有两个解决方法：1. 每个容器生成和使用自己的assets目录（不太好）；2. 将assets文件夹推送到一个共享的位置。

规划技巧：使用CDN处理静态资源和动态生成资源。这样做可以提高浏览性能，容器的职责也简化到只是负责处理API请求。这样一来，你不仅可以跨容器共享assets，也可以简化容器基础设施。

时速云为企业和开发者提供应用的镜像构建、发布、持续集成/交付 （推荐阅读：Docker如何实现CI持续集成部署）、容器部署、运维管理的新一代云计算平台。其中包括标准化、高可用的镜像构建，存储服务、大规模、可伸缩的容器托管服务，及自有主机集群混合云服务，帮助用户优化开发运维环节，提高业务效率，降低IT成本，实现持续创新。

原文链接：https://dzone.com/articles/planning-your-docker-based-microservice-stack