也许你并不需要服务化和容器化
如果你只是想构建一个简单应用，或者只是想实现一些简单的业务逻辑，那么服务化可能不是一个好的选择，当然也就更没有容器化的必要了。因为服务化不是简单的将应用拆分，容器化也不是简单的将服务打包成Docker镜像。换句话说，它们都是有“起步价”的：你不会为了一个或几个应用而构建一整套包括服务注册、配置中心、***路由、权限认证等在内的复杂架构体系，也不应该为了容器化几个服务而考虑该使用哪种容器编排工具、如何处理负载均衡、选用何种存储挂载容器卷、以及如何实现滚动升级等（可能docker-compose就足够满足你的需求）。简单地说，你可能只是需要几台虚机、几个Tomcat，搭配Nginx做负载均衡，或者再加上Keepalived做一下高可用，一个相对比较完善的架构体系就完成了。因为相对开发和运维一整套服务化和容器化的环境，这样一套简单的架构更可控，相对也就更可靠。
直到你的架构体系越来越复杂
当服务数目不多，系统架构相对简单的情况下，一切看起来还是比较美好的：当你更新了应用之后，重新打个War包；当服务副本需要增加的时候，修改一下Nginx配置；除了数据库之外，也不需要缓存、搜索引擎、消息队列这些中间件；服务挂掉之后，重启一下Tomcat。所有的一切似乎都在你的掌控，直到......
你发现业务量越来越大，单纯的依靠数据库磁盘I/O会使你的数据接口响应时间变得更长，你思考了一下，应该用上缓存。于是，你通过Redis来缓存热点数据，减轻数据库的压力；通过分布式Session让有状态服务也能够像无状态服务一样分布式部署。只不过在这个过程中，需要搭建几个Redis服务器或Redis集群。
你发现随着服务的增多，你需要更频繁地修改Nginx配置，来让你的用户或客户端请求 到后端服务层。
你发现每次更新应用，都需要修改大量的配置文件，稍有不慎就会导致配置文件出错，数据库访问不了，缓存连接不上，接口报404错误......
你发现越来越多的问题，你每天的工作很大一部分时间都是在重复性地做这些工作（当然一般运维人员更多的会使用自动化脚本和持续集成工具来替代手工操作，但是很多情况下，开发和运维真正的整合并不是看上去那么容易的）。
不是银弹，但可能你真的需要
微服务和容器化不是银弹，这是一句比较俗套但确实很有道理的一句话。服务化和容器化并不能够解决你所有的问题，但它确实改变了我们研发、运维、部署、交付应用的方式。
微服务提供的常用组件包括服务发现/注册、配置管理、***路由、断路器......
服务发现/注册可以将相同类型的服务统一化、透明化地封装成以服务名为标识的服务群组，它们拥有相同的功能，但分布在不同的计算节点。注册中心还负责不同类型服务之间的通讯，为客户端提供有效的服务地址。在你需要添加服务副本的时候，只需要将其注册到注册中心，即可为客户端提供服务，而无需关心应该怎样才能让客户端找到这个服务。
配置管理将所有服务的配置文件集中管理，可以在不重启服务的情况下推送、更新配置信息到指定的服务中。你只需要通过服务名和相应的Profile，即可在同一个模块中管理Dev、Test以及Pro等不同环境中的配置文件。
***路由通过分发、路由客户端请求，使得所有服务对外暴露同一个接口地址。还可以进一步封装粗颗粒度的接口，定制化地适配客户端的不同需求。
在你需要管理越来越多的微服务和中间件的同时，你的工作量也会随之增加。此时，容器化的优势恰恰可以解决你的问题，甚至给你带来惊喜。
所有的服务都可以通过Dockerfile打包成标准化的镜像，并通过镜像来启动和运行。只需要一个Yaml文件，就可以启动带有多个副本的服务。一些容器编排工具，如Kubernetes，可以为你提供容器编排的绝大多数功能，足够应对常见的企业级应用场景。你也可以把你的中间件容器化，此后，搭建一个MySQL集群或Redis集群只是一个配置文件和一些环境变量的问题，而无需再在各个节点安装配置数据库/缓存实例。你还可以通过一些存储解决方案，如Ceph，挂载容器需要持久化的数据卷；用EFK来搭建日志平台；用Heapster+InfluxDB+Grafana监控你的集群......
无论是开发人员，还是运维人员（或者就是DevOps），都会从服务化和容器化中受益。在你构建完整套服务化和容器云环境后，从开发人员提交代码，到应用发布到指定的环境，可能就是几秒钟的事情。
