<meta charset="utf-8">
开篇
本文主要是介绍包括微服务的概念，微服务与传统的单系统架构以及 SOA 相比较的优劣势，最后简单说了下微服务的设计原则，开发环境，部署方式。
对于了解过微服务的大佬们，这篇文章可能不存在任何有实际价值的地方，但是有些时候概念也是要了解一下的，很多时候我们虽然知道我们要描述的东西是什么但是却无法通过语言来描述出来，笔者曾经被问过：“什么是微服务？”，虽然平时大家都在说微服务，但是一旦让自己去描述的时候可能真的就无法组织好语言。
什么是微服务
就目前看来，微服务的本身并没有严格意思上的定义，每个人对微服务的理解都不同，Martin Fowler 在他的博客中这样定义了微服务的概念：
微服务架构风格是一种将单体应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务之间采用轻量级的通讯机制，这些服务围绕业务能力构建并可以通过全自动部署，这些服务共用一个最小型的集中式的管理，每个服务可以使用不同的开发语言 ，使用不同的存储技术。
总结来说微服务的本身应该具备以下特点：
- 每个服务独立运行在自己的进程中
- 一系列个服务共同组成了整个系统
- 每个服务自负责系统中某一个模块的业务功能
- 服务之间的通信采用的是轻量级的通讯机制
- 每个服务可以采用不同的开发语言以及可以使用不同的存储技术
- 全自动的部署方式
为什么使用微服务
至于为什么使用微服务，传统的思想告诉我，就像买一件商品一样，我们总会相同的价格去比较质量，相同的质量去比较价格，在我们选择微服务的时候，也很容易想到“微服务能给我们带来那些好处”，这里网络上很多大佬都给出了很多关于微服务的优势，我这里打算从三个方面去阐述这个问题：
- 传统服务（单体服务）
优势：（曾经）易开发，易测试，易部署，直到目前为止很多简单的系统任然会选择这种传 统的单服务的架构模式，其中的原因当然也是多方面的（技术，经济的角度考虑）
劣势：整个系统比较笨重，给后期的维护工作造成了 极大的压力，单系统，单存储系统， 当系统的并发量到一定的程度，显然给系统和 DB 会造成巨大的压力
- SOA
SOA的提出是在企业计算领域，就是要将紧耦合的系统，划分为面向业务的，粗粒度，松耦合，无状态的服务。服务发布出来供其他服务调用，一组互相依赖的服务就构成了SOA架构下的系统。基于这些基础的服务，可以将业务过程用类似BPEL流程的方式编排起来，而BPEL反映的是业务处理的过程，这些过程对于业务人员更为直观，调整也比hardcode的代码更容易。
当然企业还需要对服务治理，比如服务注册库，监控管理等。
我们知道企业计算领域，如果不是交易系统的话，并发量都不是很大的，所以大多数情况下，一台服务器就容纳将许许多多的服务，这些服务采用统一的基础设施，可能都运行在一个应用服务器的进程中。虽然说是面向服务了，但还是单一的系统。
- 微服务
某乎上关于微服务和 SOA 的区别讨论的话题很多，虽然二者都是面向服务的架构，但是 SOA 实际上也只是做到了业务上分离，在部署的时候还是将所有的业务的服务部署在了同一个服务器上，这样看来在并发量比较大的情况下，并没有对整个系统的服务器的压力带来缓解。
微服务则不同，不仅做到了每个服务单独运行在自己的进程中，而且每个服务之间独立部署，使用不同的 DB 系统，这样相比较 SOA 来说，不仅可以做到减少服务器的压力，而且降低了大量的 DB 操作压力
怎么用微服务
- 单一职责原则
- 服务自治原则
- 轻量级通信原则
- 微服务粒度
这里就不再解释每个职责的含义，至此不仅知道了微服务的定义，优缺点，还总结了一些指导性的设计原则，下面来看下如何实现微服务的架构
从开发和运行平台两个角度来考虑技术的选型
- 开发框架的选择：
可以使用 spring cloud 作为微服务的开发框架，不仅仅是因为spring cloud 具备开箱即用的 效果而且目前位置spring cloud 的文档，等各个方面的技术支持还算是比较全面的，当然也可以选择别的框架，如阿里的Dubbo，等这些框架。
- 运行环境：
微服务的运行并不绑定运行平台，微服务可以部署在PC Server，等云服务器上都是可以的，说到微服务的部署，不得不需要知道的就是 Docker ，它的出现给微服务的自动化部署带来极大的帮助，后面将详细的介绍微服务的 Docker 环境下的部署
