微服务之基本介绍

一、微服务架构介绍

1、微服务架构演变过程

单体应用架构->垂直应用架构一>分布式架构一>SOA架构-->微服务架构

① 单体应用架构

互联网早期，一般的网站应用流量较小，只需一个应用，将所有功能代码都部署在一起就可以，这样可以减少开发、部署和维护的成本。

传统的单体架构，也就是单点应用，也就是早期的SSM或者SSH整合项目。

采用分层架构模式、数据库访问层、业务逻辑层、控制层，从前端到后端所有的代码都是一个人写的。

比如说一个电商系统，里面会包含很多用户管理，商品管理，订单管理，物流管理等等很多模块，我们会把它们做成一个web 项目，然后部署到一台tomcat服务器上。

优点：

·项目架构简单，小型项目的话，开发成本低

·项目部署在一个节点上，维护方便

缺点：

·全部功能集成在一个工程中，对于大型项目来讲不易开发和维护

·项目模块之间紧密耦合，单点容错率低

·无法针对不同模块进行针对性优化和水平扩展

应用场景：政府项目、管理系统、crm、oa 适合于个人小团队开发。

② 垂直应用架构

随着访问量的逐渐增大，单一应用只能依靠增加节点来应对，但是这时候会发现并不是所有的模块都会有比较大的访问量。

还是以上面的电商为例子，用户访问量的增加可能影响的只是用户和订单模块，但是对消息模块的影响就比较小.那么此时我们希望只多增加几个订单模块，而不增加消息模块.此时单体应用就做不到了，垂直应用就应运而生了。

所谓的垂直应用架构，就是将原来的一个应用拆成互不相干的几个应用，以提升效率。比如我们可以将上面电商的单体应用拆分成：

·电商系统(用户管理商品管理订单管理)

·后台系统(用户管理订单管理客户管理)

·CMS 系统(广告管理营销管理)

这样拆分完毕之后，一旦用户访问量变大，只需要增加电商系统的节点就可以了，而无需增加后台

③ 分布式架构

当垂直应用越来越多，重复的业务代码就会越来越多。这时候，我们就思考可不可以将重复的代码抽取出来，做成统一的业务层作为独立的服务，然后由前端控制层调用不同的业务层服务呢?这就产生了新的分布式系统架构。它将把工程拆分成表现层和服务层两个部分，服务层中包含业务逻辑。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。

优点：

抽取公共的功能为服务层，提高代码复用性

缺点：

·系统间耦合度变高，调用关系错综复杂，难以维护

④ SOA架构

在分布式架构下，当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心对集群进行实时管理。此时，用于资源调度和治理中心(SOAService OrientedArchitecture, 面向服务的架构)是关键。

SOA面向服务架构就是基于分布式架构模式演变过来，俗称服务化，也就是面向于接口开发（服务开发）。将共同存在业务逻辑抽取成一个公共的服务，提供给其他接口实现调用，服务与服务之间采用rpc远程调用技术。

能够解决什么问题：代码冗余性问题。

SOA架构模式特点：

SOA架构模式传输协议采用SOAP协议（Http/Https+XML）实现传输，在高并发情况下实现通讯该协议存在大量的冗余性传输，而且非常占用带宽，所以在后来微服务架构中使用json替代了xml。

SOA架构模式实现方案：WebService或者ESB企业服务总线，底层采用SOAP协议传输。

传统政府、银行项目还是保留的在使用WebSercice，互联网公司肯定采用http+json形式实现传输。

优点：

·使用注册中心解决了服务间调用关系的自动调节

缺点：

-服务间会有依赖关系，一旦某个环节出错会影响较大(服务雪崩)

·服务关心复杂，运维、测试部署困难

采用SOAP协议实现通讯，xml传输非常重，效率比较低；
服务化管理和治理设施不够完善；
依赖于中心服务发现机制；
不适合于前后分离架构模式；

⑤ 微服务架构

微服务架构在某种程度上是面向服务的架构SOA 继续发展的下一步，它更加强调服务的“彻底拆分”。

微服务架构模式就是从soa架构模式演变过来的，比SOA架构模式对服务拆分粒度会更加精细，采用前后端分离的架构模式，让专业的人去做专业的事情，可以实现高效率开发。

微服务架构中，每个服务之间都是互不影响，每个服务必须要独立部署、运维、互不影响，微服务架构模式非常轻巧、轻量级，适合于互联网公司开发模式。

服务与服务之间通讯的协议采用restful形式，数据交换格式采用Http+Json格式实现传输。整个传输过程中采用二进制，所以Http协议可以实现跨语言的传输，并且和其他语言实现通讯，所以开放平台一般都是采用Http+Json格式传输。

优点：

·服务原子化拆分，独立打包、部署和升级，保证每个微服务清晰的任务划分，利于扩展

·微服务之间采用Restful等轻量级http协议相互调用

缺点：

·分布式系统开发的技术成本高(容错、分布式事务等)

2、SOA架构和微服务架构的区别

1通讯协议

微服务架构基于SOA架构模式演变过来，继承SOA架构优点，在微服务架构中去除了SOA架构中SOAP协议和ESB企业服务总线，改为Http+JSON形式传输接口。

ESB企业服务总线：解决多系统之间跨语言无法实现通讯的问题，对数据协议实现转换，可以提供可靠的消息传输，通过第三方框架实现。

一般情况下都是采用Http+JSON格式传输，所以没有必要使用ESB企业服务总线。

2服务拆分粒度

微服务架构模式比SOA架构模式粒度更加精细，提倡让专业的人去做专业的事情，目的是实现高效率的开发，每个服务与服务之间都互不影响，每个服务都是独立数据库、Redis连接、MQ等，并且都是实现独立部署，整个服务架构更加轻巧、轻量级。

在SOA架构中，有可能存在多个服务共享同一个数据库，微服务架构更加强调每个服务都是独立数据库部署，互不影响。

3迭代

微服务的架构模式比SOA架构模式更适合于互联网公司敏捷、高效、快速迭代版本开发，因为粒度非常精细。

3、微服务架构产生的原因

微服务架构基于SOA架构演变过来的，在传统的WebService架构中有如下问题: 1）依赖中心化服务发现机制；2）使用Soap通讯协议，通常使用XML格式来序列化通讯数据，xml格式非常喜欢重，比较占宽带传输；3）服务化管理和治理设施不完善
高并发和高访问量的需求：随着数据时代的发展，高访问量和高并发量越来越常见。传统的单体应用架构在处理海量数据访问时显得力不从心，难以满足新时代的需求。为了更好地应对高并发和海量数据的问题，微服务架构应运而生，通过将复杂的单体应用拆分成多个小服务单元，提高了系统的可扩展性和可用性。
技术发展的推动：随着技术的发展，各种新技术和新工具不断涌现，为微服务架构的实现提供了可能。例如，容器技术（如Docker）和自动化部署工具（如Kubernetes）使得服务的独立部署和管理变得更加容易；轻量级通信机制（如HTTP RESTful API）使得服务之间的通信更加灵活和高效。
业务快速变化的需求：在快速变化的业务环境下，企业需要能够快速响应市场变化和客户需求。微服务架构允许团队根据需要对单个服务进行快速开发和部署，从而快速适应变化的市场需求。这种灵活性使得微服务架构成为现代软件开发的重要趋势之一。