微服务的定义
微服务的流行,离不开Martin Fowler，他的博客(https://www.martinfowler.com/articles/microservices.html),
对微服务进行的概括,如果英文不行,可以查看翻译版(http://blog.cuicc.com/blog/2015/07/22/microservices/).
简单来说，微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，
服务间通信采用轻量级通信机制(通常用HTTP资源API)。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。
这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。
关于微服务的一个形象表达：
- X 轴：水平扩展，即在负载均衡服务器后增加多个运行实例
- Z 轴：数据库的扩展，即分库分表
- Y 轴：功能分解，即将不同职能的模块分成不同的服务
微服务的优缺点
微服务优点：
- 1.每个服务足够内聚，足够小，代码容易理解。这样能聚焦一个业务功能或业务需求。
- 2.开发简单、开发效率提高，一个服务可能就是专业的只干一件事，微服务能够被小团队单独开发，这个小团队可以是2到5人的开发人员组成。
- 3.微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
- 4.微服务能使用不同的语言开发。
- 5.易于和第三方集成，微服务运行容易且灵活的方式集成自动部署。
- 6.微服务易于被一个开发人员理解、修改和维护，这样小团队能够更关注自己的工作成果，无需通过合作才能体现价值。
- 7.微服务允许你利用融合最新技术。微服务只是业务逻辑的代码，不会和HTML/CSS或其他界面组件混合，即前后端分离。
- 8.每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一数据库。
微服务的缺点：
开发人员要处理分布式系统的复杂性。
微服务的理解
Monolithic(单体架构)
当网站流量很小时，只需要一个应用，所有功能部署在一起，减少部署节点成本的框架称之为集中式框架。
此时，用于简化增删改查工作量的数据访问框架(ORM)是影响项目开发的关键。
传统架构其实就是SSH或SSM，属于单点应用，把整个业务模块都会在一个项目进行开发，分为MVC架构，
会拆分成控制层、业务逻辑层、数据库访问层（持久层）。
传统架构一般适合于一个人或者小型团队开发。
缺点：耦合度太高，一旦某个模块导致服务不可用，可能会影响到其他模块。
面向服务(SOA)架构
SOA架构代表面向服务架构，俗称服务化。通俗的理解为面向于业务逻辑层开发，将共同的业务逻辑抽取出来形成的一个服务。
提供给其他服务接口进行调用，服务于服务之间调用使用rpc远程技术。
微服务的架构
微服务架构是从SOA架构中演变过来的，比SOA架构上的粒度更加精细。让专业的人做专业的事情，
目的就是为了提高效率。每个服务之间互相不受影响，每个服务必须独立部署（独立数据库、独立Redis等），
微服务架构更加轻量级，采用restful风格提供的API，也就是使用HTTP协议+json格式进行传输，更加轻巧，
更加适用于互联网公司敏捷开发、快速迭代产品。
微服务架构如何拆分：
- 微服务把每一个职责，单一功能存放在独立服务器中。
- 每个服务运行在单独进程中，能够单独启动或销毁。
- 每个服务有自己独立的数据库存储，实际上有自己独立的缓存、数据库、消息队列等资源。
微服务架构与SOA架构的区别
（1）、微服务架构基于SOA架构演变过来，继承SOA架构的优点，在微服务架构中去除SOA架构中的ESB消息总线，
采用http+json（restful）进行传输。
（2）、微服务架构对比SOA架构粒度会更加精细，让专业的人干专业的事情，目的是为了提高效率，每个服务于
服务之间互不影响。在微服务架构中，每个服务必须独立部署，微服务架构更加轻巧、轻量。
（3）、SOA架构中可能数据库存储会发生共享，微服务强调每个服务都有独立数据库，保证每个服务于服务之间互不影响。
（4）、项目体现特征，微服务架构比SOA架构更加适合于互联网公司的敏捷开发、快速迭代版本。