顾名思义，微服务就是微小的服务，这里的服务和SOA（面向服务的架构）中的服务是一个概念，举个例子，你通过百度地图API能够把一个地址转化成一个经纬度，这就是百度地图提供的一个服务。
那什么是“微”？多“微”才算微？这里有一个很重要的原则，就是“高内聚，低耦合”，一个微服务在内部必须是高内聚的，它和其它服务必须是低耦合的，如果你设计的服务和其它的服务紧密地耦合在一起，其它服务的变化会影响你的服务或者你的服务变化会要求其它服务跟着一起变化，你就享受不到微服务带来的好处。
我喜欢微服务主要是因为下面3点理由：
使用微服务之后，团队开始有机会尝试多种开发语言与新技术。 举个例子，我们之前的一个单块系统，后端一直使用Java EE，前台一直使用ExtJs，持续了很多年，开发人员都用吐了，直到我们开始把一些独立的模块从单块系统剥离出来之后，我们才开始尝鲜各种新技术，比如MongoDB, NodeJs, AngularJs和VueJs等技术。
微服务能使改变局部化。举个例子，我们开发的其中一个单块系统随着时间的变化越来越庞大，代码的编译，打包，测试和上线都要花很长的时间。即使改动了一行代码，也会触发整个系统的构建，感觉非常重量级。自从我们把一些模块剥离出来以后，我们才有机会把改动限制在一个模块之内，如果这个模块非常轻量级，上线的速度会非常快，比如我们只改了NodeJs上的一个文件，都不用编译其它任何代码，就能在1分钟之内把变动部署到线上。
微服务能避免分布式团队。如果一个单块系统很庞大，开发和运维人员就会很多，人员一多，就很有可能分布在各地。举个例子，我们有一个单块系统的成员就分布在上海，珠海和美国三地，要上线一个功能需要依赖三地同事的协同合作，很多时间都浪费在异地的沟通和等待上了。但是如果使用微服务设计，把一个大的单块系统分解成足够小的微服务，就有可能把一个微服务的所有控制权交给一个本地小团队，大幅度地减少沟通和等待的成本。同时这个小团队的积极性，主动性以及创造性也会大幅增长。
当然要享受到上述的三点好处是不容易的，怎么把一个单块系统重构成高内聚低耦合的多个相互协同的微服务绝对是一个挑战，如果你对微服务也开始感兴趣了，墙裂推荐《微服务设计》这本书，边读边实践，相信你一定会获益匪浅。
