什么是微服务

在说微服务之前让我先来谈谈项目架构的演变过程；

1.1 单一的应用架构

早期，网站访问量没多少，只需要一台服务器就绰绰有余了

1. 架构说明
   全部功能集中在一个项目里面(All in one)
2. 架构优点
   项目架构简单，前期开发成本低，周期短，小型项目的首选。
3. 缺点
   模块之间耦合度太高，其中一个升级其他都得升级
   开发困难，各个团队开发最后都要整合一起
   系统的扩展性差
   不能灵活的进行分布式部署
   技术栈受限,只能使用一种语言开发
   解决高并发只能通过集群,成本高

1.2 垂直的应用架构

随着互联网的发展，用户越来越多，当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架(MVC)是关键

1. 架构说明
   按照业务进行切割，形成小的项目，项目直接通过RPC等方式通信，交换数据等
   2.架构优点
   耦合度降低
   技术不会受限制,不同系统可以使用不同语言开发
   项目不会无限扩大
   3.缺点
   项目间公共的逻辑重复,没办法复用
   界面和业务逻辑没有分离

1.3 SOA架构

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键。流动计算架构的最佳实践阿里的Dubbo。

1. 架构说明
   将重复功能或模块抽取成组件的形式，对外提供服务，在项目与服务之间使用ESB（企业服务总线）的形式作为通信的桥梁，使用RPC等方式进行通信
2. 架构优点
   重复功能或模块抽取为服务，提高开发效率、可重用性高、可维护性高
   可以针对不同服务制定对应的技术方案。
   界面和业务逻辑实现分离
3. 架构缺点
   各系统之间业务不同，因此很难确认功能或模块是重复的，不利于开发和维护
   抽取服务的粒度大

到此SOA架构已经很接近了微服务架构了，SOA和微服务可以说是一脉相承，大神Martin Fowler提出者一概念可以说是把SOA的理念进行升华了，精进了一步。其核心思想是在应用程序开发领域，用一系列小服务实现单个应用程序的方法，或者微服务的目的是有效地分割应用程序，实现敏捷开发和部署，可以用不同的编程语言编写。SOA可以更加一般化和不那么精确。

1.4 微服务架构

说了那么多，也知道了各个架构的优缺点，接下来我们来聊聊什么是微服务

微服务体系结构是一种体系结构模式或体系结构风格，它提倡将单个应用程序划分为一组小型服务，每个服务运行在各自独立的流程中，这些服务相互协调，为用户提供最终价值。服务之间使用轻量级通信机制进行通信(通常是基于http的RESTful API)。每个服务器都是围绕特定的业务构建的，可以独立部署到生产环境、类似生产的环境等等。此外,应尽量避免联合,服务管理机制,为一个特定的服务,应该是基于业务上下文,选择适当的语言,工具,和构建,是连接到互联网来识别和翻译的轻量级集中管理协调这些服务,你可以用不同的语言编写服务,也可以使用不同的数据存储。

从开发者角度来说：微服务的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底的去耦合，每一个微服务提供单个业务功能的服务，一个服务做一件事，从务技术角度看就是一种小而独立的处理过程，类似进程概念，能够自行单独启动或销毁，拥有自己独立的数据库。

我们再来看看微服务去优缺点

1. 架构说明
   在服务治理架构上延伸，抽取的粒度更细，尽量遵循单一原则，采用轻量级框架协议(HTTP协议)传输。
2. 架构优点
   去中心化的思想，不在使用ESB作为通信的桥梁，服务、系统之间可以相互访问。
   粒度更细，有利于提高开发效率。
   可以针对不同服务制定对应的技术方案。
   适用于产品迭代周期短
3. 架构缺点
   粒度太细导致服务太多，维护成本高。
   负载均衡、事务等问题对技术团队的挑战及成本问题。

最后我们再看一下SOA和微服务的区别

功能	SOA	微服务
组件大小	大业务逻辑	单独任务或者小块业务逻辑
耦合	通常松耦合	总是松耦合
公司架构	任何类型	小型、专注于功能交叉团队
管理	着重中央管理	着重分散管理
目标	确保应用能够交互操作	执行新功能、快速拓展开发团队