众所周知，任何架构都是一步步演变而来的。没有最好的架构，只有最合适的架构。
先来看看第一代单体应用，我想这个大家也是很熟悉。大部分人入门也是从单体应用开始的。
第一代单体应用架构
这里放一个图，图中可以看到，所有模块都打包到一起，并且公用一个数据库。这种架构就是单体应用架构，也叫巨石应用。在开发小型项目上有独特的优势，易于调试、部署、运维方便，给个人开发应用的时候是比较合适的。同样，缺点也是很明显的，第一就是不可靠，一旦某个模块出现问题，可能会拖垮整个应用。然后扩展也很不方便，只能通过运行更多的服务器来进行水平扩展，比如订单服务所需要的资源较多，遇到瓶颈的时候却需要将整个应用进行扩展。还有就是不可持续发展，遇到新的技术或者框架往往需要重构所有业务模块。
于是这时候，SOA它就来了。同样先放一张图。
SOA架构
SOA是面向服务的架构，它是一种设计方法，设计通常是自上而下的，服务之间松散耦合，ESB集成不同协议的服务，做消息的转化、解释、路由从而联通各个服务，解决企业通信问题，服务松耦合、可扩展。
SOA架构有以下优点:
系统集成：在系统的角度，把原先散乱、无规划的系统间的网状结构，梳理成 规整、可治理的系统间星形结构，这一步往往需要引入一些产品，比如 ESB、以及技术规范、服务管理规范；这一步解决的核心问题是【有序】
系统的服务化：站在功能的角度，把业务逻辑抽象成 可复用、可组装的服务，通过服务的编排实现业务的 快速再生，目的：把原先固有的业务功能转变为通用 的业务服务，实现业务逻辑的快速复用；这一步解决 的核心问题是【复用】
业务的服务化：站在企业的角度，把企业职能抽象成 可复用、可组装的服务；把原先职能化的企业架构转变为服务化的企业架构，进一步提升企业的对外服务能力；“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。第三步，则是以业务驱动把一个业务单元封装成一项服务。这一步解决的核心问题是【高效】
同样的，SOA架构与单体应用相比，其实还是存在中心化的一个问题，说简单点就是依旧是共用一套数据库，这里并不是说这样不好。这样的SOA架构更多的是面向于企业服务，服务的拆分粒度很大，更多的是为了复用。
于是在这个基础上，微服务产生了。
微服务
其实微服务就是去中心化的SOA扩展，每个微服务有自己独立的数据库，它强调服务彻底点组件化，一个组件就是一个服务，服务的切分粒度更小。服务之间通过轻量化的协议进行通信，可以根据服务本身独立化部署。
所以微服务有以下特点:
1.服务拆分粒度更小，每个微服务都需要满足单一职责原则，微服务本身是内聚的，因此微服务通常比较小。比如示例中每个微服务按业务逻辑划分，每个微服务仅负责自己归属于自己业务领域的功能。
2.去中性化，进一步拆分了服务间的耦合度。
3.灵活组合，在微服务架构中，可以通过组合已有的微服务以达到功能重用的目的。
4.技术异构，在一个大型系统中，不同的功能具有不同的特点，并且不同的团队可能具备不同的技术能力。因为微服务间松耦合，不同的微服务可以选择不同的技术栈进行开发。有利于系统的演进。
但是这样的设计也会带来一些其他的问题
微服务的缺点
复杂度高
微服务间通过REST、RPC等形式交互，相对于Monolithic模式下的API形式，需要考虑被调用方故障、过载、消息丢失等各种异常情况，代码逻辑更加复杂。
对于微服务间的事务性操作，因为不同的微服务采用了不同的数据库，将无法利用数据库本身的事务机制保证一致性，需要引入二阶段提交等技术。
同时，在微服务间存在少部分共用功能但又无法提取成微服务时，各个微服务对于这部分功能通常需要重复开发，或至少要做代码复制，以避免微服务间的耦合，增加了开发成本。
运维复杂
在采用微服务架构时，系统由多个独立运行的微服务构成，需要一个设计良好的监控系统对各个微服务的运行状态进行监控。运维人员需要对系统有细致的了解才对够更好的运维系统。
影响性能
相对于SOA和单体应用架构，微服务的间通过REST、RPC等形式进行交互，通信的时延会受到较大的影响。
