第一，微服务有按需伸缩的特点。按需伸缩是微服务的优点也是它的缺点。它的缺点是会带来部署与监控运维的成本，每个部署都要监控要运维，每个微服务后面都包含一个缺点。
第二，每个微服务都可以独立部署，但它的缺点是增加机器数量与部署成本。
第三，业务独立。微服务的业务很独立，但有服务依赖、治理、版本管理、事务处理的缺点。
第四，技术多样性。它带来的成本是环境部署成本，因为每个语言环境不同。以及约定成本，和跨语言如何调，都是成本。
微服务如何治理?
当了解微服务的优缺点之后，自然会考虑到如何治理微服务，可以通过以下几点进行治理：
第一，运行状态治理。监控、限流、SLA 、LB 、日志分析，都有一些成熟的开发组件，现在有开源版本的也有云端服务，比如做性能监控的 APM SaaS 等。限流不需要做多么复杂的东西，SLA 自己有日志分析就可以。
第二，服务注册与发现，现在已有一些比较完善的解决方案。
第三，部署。部署和布置上的成本大部分被解决了，不管是用容器还是虚拟机，都可以快速部署、快速复制镜像，再进行扩容。当本机上的线上环境所有服务都布好了，在本地开发是最方便的，且不依赖于其他同事提供服务软件。
第四，调用。注重安全、容错、服务降级、调用延迟。
服务注册
服务注册有两种方案：第一种是客户端发现，第二种是服务端发现。这两种方案是很主流的方案，都有各自的优缺点。下面就是对这两种方案的介绍。
客户端发现
首先分析客户端发现。所有的路由表信息存在客户端，客户端知道应该调用哪台机器设备的哪个微服务后，再去做相应的 Load Balance ，比如微服务有四个服务，每个服务的权重都推送到客户端里，客户端再决定调用哪个服务。客户端拥有所有微服务的服务器列表和端口，每个客户端和 Service Registry 都会保持一个长连接，常见做法是每个客户端和 Service Registry 建立一个连接，当微服务后台增加或减少一个微服务，都可以实时地通知客户端。但是这个方案也存在优缺点。下面就是对其优缺点的分析。
优点：快，可以直接跟微服务直连。
缺点：
Service Registry 很多时候会成为一个瓶颈，当客户端越多瓶颈越明显，任何一个微服务有更新，都必须通知所有客户端，对实时性的要求比较高。
升级痛苦。因为微服务嵌在客户端，很难知道哪些内部用户是用哪个版本的 API ，同时也很难约定大家在同一个时间升级。
维护成本高。
服务端发现
服务端发现，通常的服务范围是，所有对外提供服务的接口，七牛用的也是这个方式，因为有成千上万个客户端，不可能把路由表写在七牛的客户端上面。当然这种方式也存在优缺点。
优点是：所有的服务可控。增加或删除一个服务时，不需要通知客户端，所有客户端可以脱离管控范围。
缺点：
治理效率和瓶颈是一个很难的问题。
标准的 HTTP 协议问题不大，如果是自定义协议会很麻烦，需要做的工作会很多。
微服务的部署
平台
微服务的部署和治理跟云平台没有必然的联系，用微服务并不意味着只能用容器，仍然可以用 IaaS 、 PaaS 、老的数据中心等平台，这个跟基础设施并没有多大的关系，但使用容器可以更好的解决某些方面的问题。
手段
部署方式一般分为手动部署和使用脚本来自动化部署。大公司有基础设施自动化、应用部署自动化平台，一点按钮就可以完成测试、打包、上线、监控、部署，但是小公司基本上没有这种基础设施建设。目前还没有公司把基础设施建设进行开源，因为每个公司的基础设施自动化测试不同，业务场景不同，所以不一定适用。
应用的自动化部署。 2010 年 PaaS 很火，很多人想把这个部署做成自动化。因为当部署应用特别方便的时，大家才愿意做拆分。管理一台机器，部署一件事情、一个服务，跟部署十个是有明显的时间成本的，如果时间成本降低，大家更愿意进行拆分。
还有一种方式是 Image 的部署。把虚拟机打包成一个镜像(它的扩展很迅速)，常见做法是镜像里面不放代码而是放脚本。每次部署一个新的用户服务时，需要到上面取一个最新的包来部署新的工作，而不是把代码放上去。因为镜像的制作成本比较高，更新麻烦。