引言：

由于公司商业上有实打实的需求和场景，倒逼产品开始思考架构升级，以适应这种商业环境的快速变化。架构师在进行技术选型或者架构升级前，需要做大量技术调研、竞品分析，《微服务架构综述》则是对服务化架构技术调研产生的调研报告，将会从如下三个角度分析微服务架构的“前生今世”，从而为产品团队的技术转型找到一些理论依据：

1. 什么是微服务架构，其与传统架构区别联系
2. 为什么要向微服务架构转型
3. 微服务架构实践

#什么是微服务架构，其与传统架构区别联系

##微服务架构定义

微服务的概念最早是在2014年由Martin Fowler和James Lewis共同提出

###Martin Fowler本人主页对微服务描述

The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.[2]

• 一套小服务
• 独立进程
• 轻量级通信协议
• 可独立部署
• 多语言&不同储技术

###维基百科定义

• 微服务是由单一应用程序构成的小服务，拥有自己的进程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用HTTP API通讯
• 服务会使用最小规模的集中管理（例如Docker）技术，服务可以用不同的编程语言与数据库等

###亚马逊对微服务架构的定义

• 微服务是一种开发软件的架构和组织方法，其中软件由通过明确定义的 API 进行通信的小型独立服务组成。
• 这些服务由各个小型独立团队负责。
• 微服务架构使应用程序更易于扩展和更快地开发，从而加速创新并缩短新功能的上市时间。

###阿里巴巴对微服务架构的定义[3]

微服务能够将业务单元按照独立部署和发布的标准进行抽取和隔离，一个大而全的复杂应用程序能够拆分成几个微小的相互独立的微服务，当其中的某一服务无法支撑时，可以横向水平扩展保证应用的高可用性，具有独立应用生命周期管理、独立版本开发与发布等能力。

##web应用架构演进

###单机架构[4]

​###集群架构[4]

​

​

###业务垂直拆分(分布式架构)[4]

​

​​

###服务化架构（SOA）[4]

垂直拆分业务后新问题：

​

 引入SOA解决：

​

​

###微服务架构[4]

​

​

 微服务拆分建议：

​

 ###MVC、RPC、SOA与微服务架构区别联系[9][10]

​

SOA架构的核心思想：

RPC架构	SOA
​	​

跟 SOA 相提并论的还有一个 ESB（企业服务总线），简单来说ESB就是一根管道，用来连接各个服务节点。为了集成不同系统，不同协议的服务，ESB 可以简单理解为：它做了消息的转化解释和路由工作，让不同的服务互联互通；将各个应用之间彼此的通信全部去掉，在中间引入一个ESB企业总线，各个服务之间，只需要和ESB进行通信，这个时候，各个应用之间的交互就会变得更加的清晰，业务架构/逻辑等，也会变得很清楚。原本杂乱没有规划的系统，梳理成了一个有规划可治理的系统，在这个过程中，最大的变化，就是引入了ESB企业总线。

SOA架构与微服务架构：

微服务架构其实和SOA架构类似，微服务是在SOA上做的升华。微服务架构重点强调的一个是"业务需要彻底的组件化和服务化"，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。微服务不再强调传统SOA架构里面比较重的ESB企业服务总线，同时SOA的思想进入到单个业务系统内部实现真正的组件化。

注：最后一句话是二者最大区别，解读：

• 所谓微服务架构不再强调ESB，是指微服务采用更轻量的消息中间件、rest API等方案来替代传统ESB，减少对SOA架构中ESB总线的依赖，并降低ESB的设计难度。并且不强调并不意味着不需要，微服务需要统一的服务管控和治理平台，按照当前微服务架构的整体思路，虽然单个服务的实现和发布仍然是在组件内部完成的，但是这些组件暴露的服务本身的调用情况，服务本身的安全，日志和流量控制等仍需要SOA服务管理平台。由于微服务尽量都是通过HTTP API的方式暴露出去的，因此这种服务管理平台不需要像传统企业内部的ESB服务总线这么重。但是最基本的服务注册，服务代理，服务发布，服务简单的路由，安全访问和授权，服务调用消息和日志记录这些功能还是需要具备。比如Dubbo架构，即可以做为微服务架构下的服务管控平台
• 微服务架构里面强调了单个组件本身是可以在独立的进程里面运行，各个组件之间在部署的时候就能够做到进程级别的隔离。那么一台服务器我们可能需要初始化几十个甚至更多的进程来进行应用组件的部署。为了保持进程的隔离性，我们可以用虚拟机，但是当几十个进程都完全用独立的虚拟机就不现实的，而这个问题的解决刚好就是利用PaaS平台里面的轻量Docker容器来做这个事情，每个Docker是独立的容器刚好又完全做到进程级别的隔离，资源占用率又最小，这些特点刚好满足微服务架构的基础设施自动化（devops、自动化运维）。

参考：

[1] Spring Cloud Alibaba 新一代微服务解决方案

[2] Martin Fowler个人主页微服务文章

[3] 阿里云微服务方案

[4] 《人人都是架构师》

[5] 齐商银行：行级分布式微服务系统架构

[6] 微服务架构优缺点

[7] Contino是一家英国非上市科技咨询服务商，Contino帮助客户加速采用云原生技术

[8] 知乎-微服务框架有哪些?

[9] 知乎-彻底搞清楚！SOA和微服务的区别

[10] 知乎-SOA和微服务架构的区别？

[11] CSDN-Spring Cloud 微服务解决方案 详解

[12] SpringCloud之熔断器Hystrix

[13] Spring Cloud 微服务中搭建 OAuth2.0 认证授权服务

[14] 微服务的用户认证与授权