微服务包括哪些

微服务包括哪些？下面让我们一起来了解一下吧。

微服务（或微服务架构）是一种云原生架构方法，其中单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成。这些服务通常：

1、有自己的堆栈，包括数据库和数据模型；

2、通过REST API，事件流和消息代理的组合相互通信；

3、它们是按业务能力组织的，分隔服务的线通常称为有界上下文。

4、尽管有关微服务的许多讨论都围绕体系结构定义和特征展开，但它们的价值可以通过相当简单的业务和组织收益更普遍地理解。

5、可以更轻松地更新代码。

6、团队可以为不同的组件使用不同的堆栈。

7、组件可以彼此独立地进行缩放，从而减少了因必须缩放整个应用程序而产生的浪费和成本，因为单个功能可能面临过多的负载。

微服务也可以通过它们不是什么来理解。微服务架构最经常得出的两个比较是整体架构和面向服务的架构（SOA）。

微服务和整体架构之间的区别在于，微服务由许多较小的，松散耦合的服务组成一个应用程序，与大型，紧密耦合的应用程序的整体方法相反。

微服务和SOA之间的差异可能不太清楚。虽然可以在微服务和SOA之间形成技术对比，尤其是围绕企业服务总线（ESB）的作用，但将差异视为范围之一更容易。SOA是企业范围内的一项工作，旨在标准化所有服务之间相互交流和集成的方式，而微服务体系结构则是特定于应用程序的。

微服务在管理人员和项目负责人中至少与在开发人员中一样受欢迎。这是微服务的较不寻常的特征之一，因为架构热情通常是为实际工程师保留的。这样做的原因是微服务更好地反映了许多业务主管想要组建和运行其团队以及开发流程的方式。

换句话说，微服务是一种架构模型，可以更好地促进所需的运营模型。

以上就是小编今天的分享了，希望可以帮助到大家。

微服务包括哪些方面

第0章：总有一篇概述告诉你什么是微服务

终身学习、乐于分享、共同成长！

零：前言

滚滚长江东逝水，浪花淘尽英雄。随着互联网的发展，网站规模越来越庞大，各路架构英雄纷纷涌现，可谓是长江后浪推前浪，从互联网早期到现在，系统架构大致经历了如下的发展历程：单体应用架构➜垂直应用架构➜分布式架构➜SOA架构➜微服务架构，还有正在兴起的Service Mesh(服务网格化)。接下来分别了解下各路架构英雄到底是怎样的，以及它们都有什么优缺点。

壹：单体应用架构

首先登场的第一位英雄是单体应用架构。所谓单体应用就是将所有的模块代码都放在一个项目工程里面，在上线部署时只需要部署一个应用即可，这样可以减少开发、部署和维护成本。

互联网早期的很多项目基本都是这么干的，比如一个电商系统，它里面包含有商品模块、订单模块、支付模块、用户模块等等XXX模块，我们会把这些统统会放到一个项目工程中，然后打包成一个war包，然后部署到Tomcat、Jetty这样的web容器中运行。

相信有一定工作年限的程序员们都玩过这个英雄，反正我是玩过，不小心暴露了年龄

优点：

• 项目架构简单，对于小型项目的开发低。
• 部署简单，只部署在一个节点上，维护简单。

缺点：

• 难开发及运维，对于大型项目来说不易开发和运维。
• 紧耦合，模块与模块之间紧耦合，不易维护。
• 难扩展，无法针对单个模块进行性能调优以及水平扩容。

貳：垂直应用架构

单体架构的优点和缺点都特别明显，随着互联网的飞速发展，越来越多人开始上网，网站的访问量越来越大，对于单体架构下的应用要想抗住如此大的访问量，那就得增加部署节点，通过负载均衡来分流承接访问量，但是并不是所有的模块都会有很大的访问量。

还是以电商系统为例，访问量比较大的模块可能只是商品模块、订单模块以及支付模块，但是对于消息模块的访问量就比较少了，那么此时我只想增加商品、订单以及及支付模块的部署节点，但对于消息模块则不增加，显然单体架构就不能实现了，这时候第二位英雄就出现了垂直应用架构。

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

应用拆分成:

• 电商系统(用户管理 商品管理 订单管理)
• 后台系统(用户管理 订单管理 客户管理)
• CMS系统(广告管理 营销管理)

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

优点：

• 系统拆分后实现了流量分担，解决了并发问题，且可以针对特定模块进行性能优化以及水平扩容。
• 提升容错率，一个系统出现问题不会导致整个应用不可用。

缺点：

• 系统之间相互独立，无法相互调用。
• 系统之间相互独立，会出现重复的开发工作。

叁：分布式架构

随着业务需求量增多，需要的垂直应用也越来越多，对重复代码的拷贝也就越来越多，这时候就可以把重复的代码单独抽离出来，形成统一的业务层作为独立的服务，这就出现了我们的第三位架构英雄了，分布式应用架构。

将项目工程拆分成表现层和业务层，表现层处理与前端的交互，业务层处理业务逻辑。前端调用表现层接口，所有的业务逻辑都由业务层实现，表现层只做参数接收➔调用业务层→返回响应参数的功能。

优点：

• 这种架构设计的缺点很明显，就是抽取公共的功能为服务层，提高代码复用性。

缺点：

• 随机也带来了一定的缺点，最明显的一点是随着服务越来越多，系统间耦合度变高，调用关系错综复杂，后续难以维护。

肆：SOA架构

随着业务的发展，在分布式架构的基础上开发的服务越来越多，对于容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心对集群进行实时管理。此时，用于资源调度和治理中心(SOA Service Oriented Architecture)是关键。

SOA是面向服务的架构，它最基本的业务功能单元是服务，将各个系统的不同功能单元抽象为服务，实现不同模块的解耦，服务间彼此通过标准的接口协议连接起来，从而实现各异构系统间的服务调用、消息交换和资源共享，并以此完成特定功能的实现。而不同服务间通信的桥梁，就是由服务总线(ESB)担当的，通过ESB完成业务系统与其他系统功能调用的统一接入，业务系统和公共功能作为标准服务在总线上公开，隔离服务消费者和服务提供者的技术实现细节，实现松耦合。

ESB的接口协议是采用中立的方式进行定义的，它独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务能够通过统一和通用的方式进行交互。

优点：

• 使用治理中心（ESB\Dubbo）解决了服务间调用关系的自动调节。
• 在调用协议上实现了统一，屏蔽了异构系统间的调用细节。

缺点：

• 使用中心化的ESB进行服务协调，容易出现服务雪崩。
• 服务关系复杂，测试、运维部署困难。

伍：微服务架构

微服务架构在某种程度上是SOA架构继续发展的下一个方向，它强调将服务进行“彻底拆分”。

微服务(Microservices)意味着每个服务要足够小，这里的小不是指代码量少，而是指职责单一，也就是要符合SRP(单一职责) 原则的才叫微服务。

设计模式六大原则

• 单一职责原则
• 里氏替换原则
• 依赖倒置原则
• 接口隔离原则
• 迪米特原则
• 开闭原则

SOA架构中可能数据库存储会发生共享，微服务强调每个服务都是单独数据库，保证每个服务与服务之间互不影响。项目体现特征微服务架构比SOA架构更加适合互联网公司敏捷开发、快速迭代版本，因为粒度非常精细。

优点：

• 服务职责单一，每个服务都有清晰的职责划分，易于扩展。
• 微服务之间采用Restful等轻量级http协议相互调用。

缺点：

• 分布式系统开发的技术成本高（容错、分布式事务等）。
• 复杂性更高。各个微服务进行分布式独立部署，当进行模块调用的时候，分布式将会变得更加麻烦。

陆：微服务架构概述

微服务的概念源于Martin Fowler于2014年3月25日写的一篇文章

https://martinfowler.com/articles/microservices.html

中文翻译：https://blog.cuicc.com/blog/2015/07/22/microservices/

Martin Fowler说微服务其实是一种架构风格，我们在开发一个应用的时候这个应用应该是由一组小型服务组成，每个小型服务都运行在自己的进程内；小服务之间通过HTTP的方式进行互联互通。

微服务是一个概念，是一种项目开发的架构思想。SOA的核心是面向服务的开发，也就是将传统的单体应用拆分成一个个的服务，而微服务则是在这个基础之上进行彻底的拆分(不再共享DB、去掉重量级的ESB)。

柒：主流的微服务架构技术实现

1. Dubbo：Zookeeper Dubbo SpringMVC/SpringBoot

• 通信方式：RPC
• 注册中心：Zookeeper、Redis
• 配置中心：Apollo、其他

1. SpringCloud

• 通信方式：http restful
• 注册中心：eruka / consul
• 配置中心：config
• 断路器：hystrix
• 网关：zuul
• 分布式追踪系统：sleuth zipkin

SpringCloud 是构建微服务的分布式系统的一套标准

其中，SpringCloud是对分布式系统开发技术栈做的一个通用的抽象。

捌：SpringCloudAlibaba

前面我们讲到SpringCloud是一个分布式系统开发的通用抽象，既然是抽象那就有对应的实现，而SpringCloudAlibaba就是其中的佼佼者，我们后续基于微服务架构技术栈的学习都是以SpringCloudAlibaba为主。

SpringCloudAlibaba技术栈总览

• 配置中心：基于Nacos Config实现配置集中管理、动态刷新的配置中心概念。
• 服务注册&发现：基于Nacos Discovery实现服务的注册与发现。
• 服务熔断：Sentinel是面向分布式、多语言异构化服务架构的流量治理组件，主要以流量为切入点，从流量路由、流量控制、流量整形、熔断降级、系统自适应过载保护、热点流量防护等多个维度来帮助开发者保障微服务的稳定性。
• 服务调用：OpenFeign是SpringCloud提供的一个基于Feign实现的Http客户端，支持SpringMVC restful风格请求。
• 服务路由：基于SpringCloud Gateway实现，支持服务名路由、URI等多种路由方式。
• 分布式消息：基于RocketMQ/其他MQ组件。
• 负载均衡：SpringCloud Ribbon是基于Netflix Ribbon实现的一套客户端的负载均衡工具，Ribbon客户端组件提供一系列的完善的配置，如超时，重试等。通过Load Balancer获取到服务提供的所有机器实例，Ribbon会自动基于某种规则(轮询，随机)去调用这些服务。Ribbon也可以实现我们自己的负载均衡算法。
• 分布式事务：Seata 是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务。
• 链路追踪：Skywalking是一个国产开源框架，2015年由吴晟开源 ， 2017年加入Apache孵化器。skywalking是分布式系统的应用程序性能监视工具，专为微服务、云原生架构和基于容器（Docker、K8s、Mesos）架构而设计。它是一款优秀的APM（Application Performance Management）工具，包括了分布式追踪、性能指标分析、应用和服务依赖分析等。

各路架构英雄介绍完毕，接下来让我们一起进入SpringCloudAlibaba的学习吧！