工作中常用到微服务架构，知识点零零散散，这里稍微整理一下。
微服务架构的诞生是建立在各代程序员的努力之下，先后经历了单体应用架构、垂直应用架构以及分布式应用架构，并非一朝一夕。
单体应用架构
此架构是将所有的功能集成于一个服务中，即最终会打包成一个具体的应用，例如jar,war。每个项目包括每一层每一块里编写所有的代码。例如一个web工程里面包括了前端页面，web层代码，Service层代码，DAO层代码，把这些代码打包到一个项目当中，放到web容器中启动。如图所示：
优点
开发简单，适用于小型应用
缺点
显然，这种架构易于开发、维护和部署。在用户量不多的情况下，该架构完全可以满足需求，但一旦用户量以及业务的复杂化，再加上代码的高度耦合，系统的维护和横向扩展异常困难。当用户量达到需要负载均衡来支持时，不得不使用多台服务器，但并不是应用中的每个功能模块都需要负载均衡，因此在扩展时必然会导致资源的浪费。例如：订单管理模块每秒访问1k次，用户管理每秒200次，这时扩展时连带用户管理一起扩展了，意义不大。总而言之，单体不易扩展与维护，代码的耦合度高。
垂直应用架构
由于单体应用架构的种种问题，先辈们开始考虑将各功能模块抽取成独立的子工程，每个子工程跑在一个容器中。例如：
如果用户中心访问较多，只需要针对用户中心进行扩展就可以了。
优点
解决了高并发问题
可针对不同的模块进行优化
方便水平扩展
容错性高（其中一个系统出现了问题了，不影响其他系统，只需要针对出错的系统进行停机维护即可）
缺点
系统之间相互独立：需要为相互作用系统建立联系
大量的重复工作
分布式架构
把一个垂直应用进行业务上的抽取，抽取成两部分内容。一个是基础服务，另一个是业务功能，通过业务功能去调用相应的基础服务就构成了分布式应用。这样就很好的解决了服务与服务之间的调用。例如：
优点
解决了服务与服务之间调用的问题，即减少了服务与服务之间的耦合度
缺点
随着服务层体积的增大，应用越来越多，服务的评估，治理与统一治理越来越难
面向服务的架构（SOA）
针对分布式架构缺点，形成了SOA(Service-Oriented Architecture)概念，即面向服务的架构。它可以根据需求通过网络对松散耦合的粗粒度应用组件（服务）进行分布式部署、组合和使用。一个服务通常以独立的形式存在于操作系统进程中。
站在功能的角度，把业务逻辑抽象成可利用、可组装的服务，通过服务的编排实现业务的快速再生，目的：把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速利用。比较流行的SOA有ESB,DUBBO。
优点
抽取公共的功能为服务，提高开发效率
对不同的服务进行集群化部署解决系统压力
基于ESB/DUBBO进一步减少了系统的耦合
缺点
抽取服务的粒度较大
虽然基于ESB/DUBBO进一步减少了系统的耦合，但是耦合还是存在的，且不低
微服务架构
针对SOA的缺点，新的一种架构诞生了，即微服役架构。通过对服务尽可能的拆分，直到不能拆分为上并独立打包运行，服务调用层与服务提供方通过轻量级的http协议进行交互，达到完全解耦的效果，每次交互只需要一个简单的http请求即可，无需复杂的调用技术。每个服务遵循单一职责原则，通过http接口向外提供功能。
优点
通过服务的原子化拆分，以及微服务的独立打包、部署和升级，小团队的交付周期将缩短，运维成本也奖大幅度下降
微服务遵循单一职责原则，采用restful等轻量级协议传输
缺点
微服务过多，服务治理成本高，不利于系统维护
分布式系统开发的技术成本高（容错、分布式事物等）
SOA与微服务之间的关系
SOA它是一种设计方法，其中包含多个服务，服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在于操作系统进程中。各个服务之间通过网络调用。
微服务架构 和SOA类似，它是在SOA基础上的升华，强调的重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分成多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。
| 功能 | SOA | 微服务 |
|---|---|---|
| 组件大小 | 大块业务逻辑 | 单独任务或小块业务逻辑 |
| 耦合度 | 通常松耦合 | 总是松耦合 |
| 公司架构 | 任何类型 | 小型、专注于功能交叉团队 |
| 管理 | 着重中央管理 | 着重分散管理 |
| 目标 | 确保应用能够交互操作 | 执行新功能、快速拓展开发团队 |
| 调用方式 | RPC(较重) | HTTP(较轻) |
总之，微服务的发展不是一朝一夕，也是经过多年的迭代，最终成为广受欢迎的架构。