前言

在已然拥挤的软件架构道路上又出现了一个新名词：“微服务”，虽然我们经常看不起这些时不时就冒出来的新概念，但微服务这个概念确实描述了一种非常具有吸引力的软件系统架构。现在这个架构已经非常流行了，所以单从结果论来看它都是值得肯定的，而且它已经变成了我们周围同事搭建系统的默认架构选择。但奇怪的是业内并没有太多信息来描述这个概念是什么以及怎么落地。
简单来说，微服务就是通过创建多个单应用来组成一套应用体系，每个单应用运行在独立的处理单元上，应用之间加上轻量的通信机制，比如http协议通讯。这些服务是围绕业务能力构建的，可以单独部署。微服务之间仅有少量的中心化管理措施，而且微服务还支持不同语言、不同存储体系。
为了理解微服务，我们先了解单体应用，单体应用一般分为三块：客户端浏览器，数据库，服务端应用。服务端应用通过接受浏览器请求，经过一些业务逻辑，操作数据库的数据并组装结果返回给浏览器。这种模式的问题在于单体应用会非常巨大，单次发布和部署会影响范围巨大。
其实单体应用的发展是一个非常自然的过程，所有业务逻辑都跑在同一个应用中，当然你可以通过语言的一些特性来划分这个应用内的逻辑，比如方法、类、包、命名空间等从低到高多种方式，你可以在笔记本上运行这个单体应用，或则用部署工具来完成集成测试和线上发布。你还可以通过添加负载均衡+集群来优化这个单体应用。
我们不能否认单体应用是一种有效且成功的架构模式，但随着云技术的发展，越来越多人开始嫌弃这种牵一发而动全身的发布方式。而且单体应用会随着业务发展，内部模块的划分边界也会开始模糊，这使得部署和测试更加麻烦，少量修改就需要全量回归。而上面提到的集群化，也只能针对整个应用维度，而不是正真需要扩展业务模块。
综上对比微服务的好处和单体应用的缺点，就是我们推崇微服务架构的原因。虽然我们不认为微服务架构是一种多大的创新（因为在我们看来只有unix系统架构那种级别才可以称的上创新），但微服务确实给开发人员带来了非常多的好处。

微服务架构的组成