早在1996年,Gartner最早提出SOA（面向服务架构）的概念，早期的SOA的实现方式主要是WebService，通过契约发布，契约描述，服务实现的流程来构建。早期SOA主要是解决软件与软件之间跨开发语言、跨平台的交互问题。在传统业务中WebService也算是补足业务的通讯问题。

  而微服务（MicroService For SOA）的提出，则是彻底要改变原有的开发架构，而不是补足作用。由于移动互联网的迅猛发展，开发与迭代速度越来越快。尤其是多个终端，多个平台的业务愈发的迅速发展。传统的单体模式开发架构显然已不和时宜。多个平台功能的不同步性愈发突出。业务与界面耦合性没有彻底解决，并且或多或少的存在维护问题。导致更换界面与迁移平台的成本大幅上升。早期人们就开始想有没有办法解决业务逻辑与平台的分离，他们想到WebService和其他RPC的方式，但是应用过程中发现WebService的私有协议过重，在移动平台上调用显得过于费时费力；那么RPC呢？RPC的标准参差不齐，违背互联网的开放协作原则。简单的说：传统的单体软件没有真正做到一次开发业务，跨设备、跨平台使用。不断重构界面衔接层（MV*中P，VM，C层）的代码，并且业务耦合性没彻底解决。

  微服务油然而生，通过简单的HTTP协议进行服务，抛弃以往又笨又重或者不兼容的服务协议。为了更好使用服务进行交互，人们想起Roy Thomas Fielding在他2000年的提出的RESTful风格的服务架构。通过简单的契约，更快、更好的构建通用的服务。从此业务的互通性得到了很好的解决，不断有公司尝试新的架构。

  通过将业务的调用接口粒度化的暴露出来，用简单的API文档说明业务流程。任何消费端都可以最快的使用业务。不必关系业务细节，从而快速的将业务部署到任何消费端。

  微服务带来一个结果就是：服务端重点关心 Model 层；客户端重点关心 View 层与 Presenter 或 Controller 或 ViewModel 层；分离了关注点的同时提高了开发效率。

  微服务能像传统业务一样可以部署在任何HTTP的服务器上不需要特殊的机制，并且能很好的利用HTTP协议的特征，只要能理解HTTP的基本特征就可以很快上手使用。

如图：传统单体架构（紧凑型业务逻辑，多种技术混合使用）

如图：微服务架构（松散型业务逻辑，统一部署或分布式部署，一个技术面面俱到）

微服务给传统架构带来哪些改变