【架构知识】微服务有什么认识？微服务演进？

洋气月

已于 2022-03-15 11:32:26 修改

阅读量663

点赞数

分类专栏： java学习文章标签： java windows python

于 2021-11-29 11:24:40 首次发布

本文链接：https://blog.csdn.net/arispy/article/details/121603574

版权

java学习专栏收录该内容

57 篇文章 2 订阅

订阅专栏

1，单体架构

Web应用程序发展的早期;

1,所有的功能集成在一个项目工程中;打一个war包部署到服务器。

2、应用与数据库分开部署。

3、通过部署应用集群和数据库集群来提高系统的性能。

小项目就开发快成本低，架构简单易于测试和部署，但大项目模块耦合严重不易开发和维护，新增业务很困难且核心业务和边缘业务混一起，出现问题也相互影响

这种将所有功能都部署在一个web容器中运行的系统就叫做单体架构（也叫：巨石型应用）

一个典型的单体应用就是将所有的业务场景的表示层、业务逻辑层和数据访问层放在一个工程中，最终经过编译、打包，部署在一台服务器上。

例如：典型的J2EE工程，它是将表示层的JSP、业务逻辑层的Service、Controller和数据访问层的Dao，打成war包，部署在Tomcat、Jetty或者其他Servlet容器中运行

优点：

1、项目架构简单，前期开发成本低，周期短，小型项目的首选。

缺点：

1、全部功能集成在一个工程中，对于大型项目不易开发、扩展及维护。

2、系统性能扩展只能通过扩展集群结点，成本高、有瓶颈。

3、技术栈受限。

1.2 单体架构的拆分

详细一个网站在业务大规模爬升时会发生什么事情?并发度不够?OK，加web服务器。数据库压力过大?OK，买更大更贵的数据库。数据库太贵了?将一个表的数据分开存储，俗称“分库分表”。这些都没有问题，good job。不过，老外的抽象能力比我们强，看下图Fig2。

这张图从三个维度概括了一个系统的扩展过程：

(1)x轴，水平复制，即在负载均衡服务器后增加多个web服务器;

(2)z轴扩展，是对数据库的扩展，即分库分表(分库是将关系紧密的表放在一台数据库服务器上，分表是因为一张表的数据太多，需要将一张表的数据通过hash放在不同的数据库服务器上);

(3)y轴扩展，是功能分解，将不同职能的模块分成不同的服务。从y轴这个方向扩展，才能将巨型应用分解为一组不同的服务，例如订单管理中心、客户信息管理中心、商品管理中心等等。

2，垂直架构

根据业务把项目垂直切割成多个项目，因此这种架构称之为垂直架构.

特点：

1、以单体结构规模的项目为单位进行垂直划分项目即将一个大项目拆分成一个一个单体结构项目。

2、项目与项目之间的存在数据冗余，耦合性较大，比如上图中三个项目都存在客户信息。

3、项目之间的接口多为数据同步功能，如：数据库之间的数据库，通过网络接口进行数据库同步。

优点：

1、项目架构简单，前期开发成本低，周期短，小型项目的首选。

2、通过垂直拆分，原来的单体项目不至于无限扩大。

3、不同的项目可采用不同的技术。

缺点：

1、全部功能集成在一个工程中，对于大型项目不易开发、扩展及维护。

2、系统性能扩展只能通过扩展集群结点，成本高、有瓶颈。

3，SOA

分层：按照业务性质分层，每一层要求简单和容易维护

应用层（展示层）：距离用户最近的一层也称为接入层，可以使用Tomcat作为web容器。接受用户请求，使用下游的dubbo提供的接口来返回数据，并且该层禁止访问数据库
业务服务层：根据具体的业务场景演变而来的模块，比如简历投递，职位搜书，职位推荐等
基础业务层：业务的核心
基础服务层：这一层是与业务无关的模块是一些通用的服务，这类服务的特点:请求量大逻辑简单特性明显功能独立,不易改变。
存储层：不同的存储类型 Mysql Mongodb ES fastDFS

SOA架构是面向服务的体系结构，主要目的是为了各个系统更加容易地融合在一起。

例如：以购物商城为例，由于功能模块越来越多，系统非常臃肿所有对系统进行横向拆分，各个服务之间彼此相对独立，通过服务治理框架进行服务之间的通信以及管理，常用的服务治理框架有：dubbo、dubbox等

特点：

1、基于SOA的架构思想将重复公用的功能抽取为组件，以服务的方式给各系统提供服务。

2、各各项目（系统）与服务之间采用webservice、rpc等方式进行通信。

3、ESB企业服务总线作为项目与服务之间通信的桥梁。

优点：

1、将重复的功能抽取为服务，提高开发效率，提高系统的可重用性、可维护性。

2、可以针对不同服务的特点制定集群及优化方案。

3、采用ESB减少系统中的接口耦合。

缺点：

1、系统与服务的界限模糊，不利于开发及维护。

2、虽然使用了ESB，但是服务的接口协议不固定，种类繁多，不利于系统维护。

3、抽取的服务的粒度过大，系统与服务之间耦合性高。

3. 微服务

微服务是将一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务模块。

微服务之间如何通信？

1.远程过程调用（Remote Procedure Invocation）：

也就是我们常说的服务的注册与发现。直接通过远程过程调用来访问别的service。

优点：

因为没有中间件代理，系统更简单

缺点：

只支持请求/响应的模式，不支持别的，比如通知、请求/异步响应、发布/订阅、发布/异步响应

降低了可用性，因为客户端和服务端在请求过程中必须都是可用的

2.消息：

使用异步消息来做服务间通信。服务间通过消息管道来交换消息，从而通信。

优点:

把客户端和服务端解耦，更松耦合

提高可用性，因为消息中间件缓存了消息，直到消费者可以消费

支持很多通信机制比如通知、请求/异步响应、发布/订阅、发布/异步响应

缺点:

消息中间件有额外的复杂

特点：

1、将系统服务层完全独立出来，并将服务层抽取为一个一个的微服务。

2、微服务遵循单一原则。

3、微服务之间采用RESTful等轻量协议传输。

优点：

1、服务拆分粒度更细，有利于资源重复利用，提高开发效率。

2、可以更加精准的制定每个服务的优化方案，提高系统可维护性。

3、微服务架构采用去中心化思想，服务之间采用RESTful等轻量协议通信，相比ESB更轻量。

4、适用于互联网时代，产品迭代周期更短。

缺点：

1、微服务过多，服务治理成本高，不利于系统维护。

2、分布式系统开发的技术成本高（容错、分布式事务等），对团队挑战大。

3.2 微服务消息

1）同步消息 – REST, Thrift

同步消息就是客户端需要保持等待，直到服务器返回应答。REST是微服务中默认的同步消息方式，它提供了基于HTTP协议和资源API风格的简单消息格式，多数微服务都采用这种方式（每个功能代表了一个资源和对应的操作）。

Thrift是另外一个可选的方案。它采用接口描述语言定义并创建服务，支持可扩展的跨语言服务开发，所包含的代码生成引擎可以在多种语言中，如 C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk 等创建高效的、无缝的服务，其传输数据采用二进制格式，相对 XML 和 JSON 体积更小，对于高并发、大数据量和多语言的环境更有优势。

2）异步消息 – AMQP, STOMP, MQTT

异步消息就是客户端不需要一直等待服务应答，有应到后会得到通知。某些微服务需要用到异步消息，一般采用AMQP, STOMP, MQTT。

3）消息格式 – JSON, XML, Thrift, ProtoBuf, Avro

消息格式是微服务中另外一个很重要的因素。SOA的web服务一般采用文本消息，基于复杂的消息格式（SOAP）和消息定义（xsd）。微服务采用简单的文本协议JSON和XML，基于HTTP的资源API风格。如果需要二进制，通过用到Thrift, ProtoBuf, Avro。

4）服务约定 – 定义接口 – Swagger, RAML, Thrift IDL

如果把功能实现为服务，并发布，需要定义一套约定。单体架构中，SOA采用WSDL，WSDL过于复杂并且和SOAP紧耦合，不适合微服务。

REST设计的微服务，通常采用Swagger和RAML定义约定。

对于不是基于REST设计的微服务，比如Thrift，通常采用IDL（Interface Definition Languages），比如Thrift IDL。

4，SOA vs 微服务

微服务定义中的任何一个系统都应该可以独立部署、独立运行，并能独立完成一个业务闭环。如果你的系统在启动之后，并不能对外提供什么实质的功能，而是要完全依赖其它的服务，那这个系统就不算一个独立的系统。
微服务又和同样是最近几年说的比较多的SOA架构有什么区别和联系呢。

首先微服务架构和SOA架构都是一种基于分布式系统的而且面向服务的架构风格，这里请注意，是“风格”，不是框架。这些概念的提出只是给我们定义了它的规范和原则，并没有给我们输出可以直接落地的技术方案。那它们有什么区别吗，如果只从定义上好像很难说的清。但是从它们实践的过程和方式上来看，还是有很大区别的。下面我从几个主要方面说一下．

领域驱动设计（DDD）：

笔者认为这应该是最重要的一点，微服务的提出最根本原因是解决越来越复杂的系统设计与开发的问题。当系统过于复杂时，它所面临的问题难度要比只有几个简单功能的系统面临问题难度大得多。而原因就在于系统内部已经有了太多的耦合，系统的每一次迭代都可能是致命的，而DDD理论的出现就是为了解决这样的问题。微服务把它作为了业务划分的重要指导理论依据。

去中心化：

SOA在提出时有一个重要的角色ESB（企业服务总线），它的根本是协调各系统进行功能输出，所以天生就是一个带有中心角色的架构，而微服务是去中心化的，它认为任何单独的服务都可以独立自治，不受其它系统的制约和调配。

独立数据库：

服务要保持独立自治性，就应该完全使用自己的数据库，而不是和别的系统共用。当自己的业务模型发生修改时，只修改自己内部的数据结构就可以了，而且也不用关心会对其它服务产生影响，而SOA中并没有对这个原则有明确的要求。