对微服务架构的理解

一、微服务架构

1、系统架构与设计的三个阶段

集中式架构：

        就是把所有的功能、模块都集中到一个项目中，部署在一台服务器上，从而对外提供服务（也称单体架构、单体服务、单体应用）；

        特点：只有一个项目，只有一个war；

分布式架构：

        就是把所有的功能、模块拆分成不同的子项目，部署在多台不同的服务器上，这些子项目相互协作共同对外提供服务。

特点：就是有很多项目，有很多war包，这些项目相互协作完成需要的功能，由多个war包来完成的；

微服务架构：

        分布式架构强调系统的拆分，微服务架构也是强调系统的拆分，所以微服务架构属于分布式架构的范畴；下面谈谈微服务的由来：

        面向服务架构（SOA）就是把一个大型的单体程序，拆分成一个个独立服务(程序)，每个服务都是一个独立的功能单元，专注于完成系统中的某一项业务功能，职责单一，服务之间通过通信协议连在一起。以下是其他博主的博客关于SOA的描述：

SOA（Service-Oriented Architecture，面向服务的架构）是一种在计算机环境中设计、开发、部署和管理离散模型的方法。SOA是在企业内部IT系统重复构建以及效率低下的背景下提出的。

在SOA模型中，所有的功能都被定义成了独立的服务，所有的服务通过服务总线(ESB)或流程管理器来连接。这种松散耦合的结构使得能够以最小的代价整合已经存在的各种异构系统，当然，由于需要实现对各种异构系统的适配(通常使用ESB来完成不同系统之间的协议转换及数据格式转换)，因此，其本身也会引入更多的复杂性。
————————————————
版权声明：本文为CSDN博主「牧羊女说」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/DeliaPu/article/details/119912932

微服务架构与面向服务架构的联系

You should instead think of microservices as a specific approach for SOA
in the same way that XP or Scrum are specific approaches for Agile software development.

引用自 《Building Microservices》 一书

        早期企业软件业界自己摸索了一套实践方式（ESB企业服务总线）。经过历史证明，ESB 的实现方案并未取得成功。所以微服务架构的拥护者拒绝使用SOA这个标签，而直接称其为微服务架构（Microservices Architecture Style）。

        就是说微服务架构就是脱胎于SOA的一个特定的实践方法。微服务架构强调 “微”（强调每个服务一个进程），所以微服务架构是在 SOA 架构思想的基础上，对服务做进一步的拆分，使用进程为边界来隔离代码库，每个微服务的规模大小控制在一个普通程序员的舒适维护区能力范围内（据说大部分普通程序员成长生涯的瓶颈在 2 万行代码左右）。

微服务拆分时的几个原则：

• 不同微服务，不要重复开发相同业务
• 微服务数据独立，不要访问其它微服务的数据库
• 微服务可以将自己的业务暴露为接口，供其它微服务调用

常见的系统架构遵循的三个标准和业务驱动力：

• 提高敏捷性：及时响应业务需求，促进企业发展
• 降低成本：降低增加产品、客户或业务方案的成本
• 提升用户体验：提升用户体验满意度，减少用户流失

每个服务都是一个独立的项目，可以进行独立的开发、测试和部署等；

2、微服务架构的定义

        微服务（Microservice）这个概念是2012年由Martin Fowler提出的，作为加快Web和移动应用程序开发进程的一种方法，2014年开始受到各方的关注，而2015年是微服务的元年；可以说微服务的流行，Martin 功不可没，他特别擅长抽象归纳和制造概念。

官方定义：

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.
-- James Lewis and Martin Fowler

        所谓服务（service），就是在后台不间断运行、提供某种功能的一个程序。最常见的服务就是 Web 服务，通过80端口向外界提供网页访问。

        微服务：一种可扩展的SOA的实现方法，它通过构建细粒度的服务来提供支持分布式的、按功能域组织的业务能力；可以认为是一种经过良好架构设计的分布式架构方案。

微服务架构的特点

• 单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责
• 自治：团队独立、技术独立、数据独立，独立部署和交付
• 面向服务：服务提供统一标准的接口，与语言和技术无关
• 隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题

二、微服务架构的组成及其基本原理

1、微服务架构的组成及其基本原理

        通过对微服务架构技术栈进行总结，对其落地技术（每家公司的技术方案应该不太一样）及其作用进行汇总描述，形成本人对于微服务架构的组成和基本原理的基本理解，具体如下：

微服务条目	落地技术	作用描述
服务开发框架	Spring boot、Spring cloud等	1、Spring Boot:旨在简化创建产品级的 Spring 应用和服务，简化了配置文件，使用嵌入式web服务器，含有诸多开箱即用微服务功能，可以和spring cloud联合部署 2、Spring Cloud：微服务工具包，为开发者提供了在分布式系统的配置管理、服务发现、断路器、智能路由、微代理、控制总线等开发工具包（组件）。
负载均衡	Nginx，Ribbon	1、服务器端负载均衡Nginx：客户端所有请求统一交给nginx，由nginx进行实现负载均衡请求转发 2、客户端负载均衡Ribbon：从eureka注册中心服务器端上获取服务注册信息列表，缓存到本地，让后在本地实现轮训负载均衡策略。
服务网关 API Gateway	自研网关，基于zuul	1、为微服务架构的系统提供简单、有效且统一的API路由管理，给客户端提供统一的服务，作为系统的统一入口，提供内部服务的路由中转。 2、可以实现一些和业务没有耦合的公用逻辑，主要功能包含路由转发、认证、鉴权、流量控制、安全策略、防刷、监控日志等。
注册中心服务（包括服务发现）	Erueka(spring erueka)，用于实现服务注册和服务发现。 服务发现指的就是用户可以通过服务标识，在注册中心找到提供对应的服务的实例的网络地址（ip+port)	1、注册服务信息：服务提供者将自身信息注册到eureka-server，其保存服务名称到服务实例的网络地址列表的映射关系 2、拉去服务信息：根据服务名称，拉取实例地址列表
配置中心	阿里云的nacos	1、是一个分布式配置中心组件，方便配置文件集中管理 2、动态配置管理：可以在配置变更时，及时通知微服务，实现配置的热更新 3、服务发现和服务健康监测：Nacos 提供对服务的实时的健康检查，阻止向不健康的主机或服务实例发送请求 4、动态 DNS 服务：服务发现的未来一定是基于标准的 DNS 协议做，而不是像 Eureka 或者像 ZooKeeper 这样的私有 API 或者协议做, 同时在云上，在服务发现场景中，注 册中心更关注的是可用性而不是数据一致性
服务通信	1、同步调用： ①REST（JAX-RS，Spring Boot） ②RPC（Thrift, Dubbo） 2、异步消息调用(Kafka, Notify, MetaQ、Rocketmq)	1、jax-rs 是基于REST设计风格的WebServcice提供的API，支持按照表述性状态转移(REST)架构风格创建Web服务，同时它为dubbo提供了接近透明的REST调用支持 2、Dubbo：是阿里巴巴开源的基于 Java 的高性能RPC（远程服务调用） 分布式服务框架，可以通过网络从远程计算机程序上请求服务 3、thrift主要用于各个服务之间的RPC通信，支持跨语言。 4、Kafka是一种消息队列，主要用来处理大量数据状态下的消息队列，一般用来做日志的处理 5、Notify是淘宝自主研发的一套消息服务引擎。与传统的MQ不同，Notify是为了消息堆积而设计系统，无单点，可自由扩展的设计 6、MetaQ是一款完全的队列模型消息中间件，具有高性能、高可靠、高实时、分布式特点 7、RocketMQ作为一款纯java、分布式、队列模型的开源消息中间件，支持事务消息、顺序消息、批量消息、定时消息、消息回溯等
服务调用	Spring Cloud Feign	1、Feign是一种声明式、模板化的 HTTP 客户端，可以做到使用 HTTP 请求访问远程服务 2、Feign整合Hystrix熔断器 3、SpringCloudFeign支持对请求和响应进行GZIP压缩，以减少通信过程中的性能损耗
服务监控(容错)	Hystrix Dashboard/Sentinel，用于监控服务器集群运行状况	1、Hystrix Dashboard：对应Spring cloud，是用于处理分布式系统的延迟和容错的开源库，提供服务降级、服务熔断、服务限流和资源隔离等特性 2、Sentinel：对应Spring cloud Alibaba，是阿里开源的项目，提供了流量控制、熔断降级、系统负载保护等多个维度来保障服务之间的稳定性
服务部署	Docker、Kubernetes 微服务部署的关键要求如下： 能够独立于其他微服务部署/部署。 必须能在每个微服务级别做扩展（给定的服务可能比其他服务获得更多的流量）。 快速构建和部署。 一个微服务的故障不得影响任何其他服务。	1、Docker：提供了一种很好的方式来部署满足微服务部署关键要求的微服务器 2、Kubernetes：通过允许将一组Linux容器作为单个系统进行管理，在多个主机上管理和运行Docker容器，提供容器的共同位置，服务发现和复制控制，从而扩展Docker功能
数据服务集群	Mysql，redis，Mongodb	省略
日志采集	ELKB 是一个完整的分布式日志收集系统，很好地解决了上述提到的日志收集难，检索和分析难的问题。ELKB 分别是指 Elasticsearch、Logstash、Kibana 和 Filebeat。	1、Elasticsearch 是实时全文搜索和分析引擎，提供搜集、分析、存储数据三大功能；是一套开放 REST 和 JAVA API 等结构提供高效搜索功能，可扩展的分布式系统 2、logstash 是一个数据分析软件，主要目的是分析 log 日志 3、Kibana 是一个基于 Web 的图形界面，用于搜索、分析和可视化存储在  Elasticsearch 指标中的日志数据。Kibana 调用 Elasticsearch 的接口返回的数据进行可视化。它利用 Elasticsearch 的 REST 接口来检索数据，不仅允许用户创建他们自己的数据的定制仪表板视图，还允许他们以特殊的方式查询和过滤数据。 4、Filebeat 用于转发和集中日志数据的轻量级传送工具。Filebeat 监视指定的日志文件或位置，收集日志事件，并将它们转发到 Logstash、Kafka、Redis 等，或直接转发到 Elasticsearch 进行索引。
全链路追踪	Zipkin，Pinpoint，SkyWalking，Spring Cloud Sleuth	1、Zipkin：由Twitter公司开源，开放源代码分布式的跟踪系统，用于收集服务的定时数据，以解决微服务架构中的延迟问题，包括：数据的收集、存储、查找和展现。 2、Pinpoint：一款对Java编写的大规模分布式系统的APM工具，由韩国人开源的分布式跟踪组件。 3、Skywalking：国产的优秀APM组件，是一个对JAVA分布式应用程序集群的业务运行情况进行追踪、告警和分析的系统。 4、Spring Cloud Sleuth：在整个分布式系统中能跟踪一个用户请求的过程(包括数据采集，数据传输，数据存储，数据分析，数据可视化)，捕获这些跟踪数据，就能构建微服务的整个调用链的视图

三、微服务架构的具体实践

要实际的应用微服务，需要解决一下四点问题：

1、客户端如何访问这些服务

2、每个服务之间如何通信

3、如此多的服务，如何实现？

4、服务挂了，如何解决？（备份方案，应急处理机制）

1、客户端如何访问这些服务

原来的Monolithic方式开发，所有的服务都是本地的，UI可以直接调用，现在按功能拆分成独立的服务，跑在独立的一般都在独立的虚拟机上的 Java进程了。客户端UI如何访问他的？

后台有N个服务，前台就需要记住管理N个服务，一个服务下线/更新/升级，前台就要重新部署，这明显不服务我们 拆分的理念，特别当前台是移动应用的时候，通常业务变化的节奏更快。

另外，N个小服务的调用也是一个不小的网络开销。还有一般微服务在系统内部，通常是无 状态的，用户登录信息和权限管理最好有一个统一的地方维护管理（OAuth）。

所以，一般在后台N个服务和UI之间一般会一个代理或者叫API Gateway，他的作用包括：

① 提供统一服务入口，让微服务对前台透明

② 聚合后台的服务，节省流量，提升性能

③ 提供安全，过滤，流控等API管理功能

其实这个API Gateway可以有很多广义的实现办法，可以是一个软硬一体的盒子，也可以是一个简单的MVC框架，甚至是一个Node.js的服务端。他们最重要的作 用是为前台（通常是

移动应用）提供后台服务的聚合，提供一个统一的服务出口，解除他们之间的耦合，不过API Gateway也有可能成为单点故障点或者性能的瓶颈。

用过Taobao Open Platform（淘宝开放平台）的就能很容易的体会，TAO就是这个API Gateway。

2、每个服务之间如何通信

所有的微服务都是独立的Java进程跑在独立的虚拟机上，所以服务间的通信就是IPC（inter process communication），已经有很多成熟的方案。现在基本最通用的有两种方式：

同步调用：

①REST（JAX-RS，Spring Boot）

②RPC（Thrift, Dubbo）

异步消息调用(Kafka, Notify, MetaQ)

同步和异步的区别：

一般同步调用比较简单，一致性强，但是容易出调用问题，性能体验上也会差些，特别是调用层次多的时候。RESTful和RPC的比较也是一个很有意 思的话题。

一般REST基于HTTP，更容易实现，更容易被接受，服务端实现技术也更灵活些，各个语言都能支持，同时能跨客户端，对客户端没有特殊的要求，只要封装了HTTP的

SDK就能调用，所以相对使用的广一些。RPC也有自己的优点，传输协议更高效，安全更可控，特别在一个公司内部，如果有统一个 的开发规范和统一的服务框架时，

他的开发效率优势更明显些。就看各自的技术积累实际条件，自己的选择了。

而异步消息的方式在分布式系统中有特别广泛的应用，他既能减低调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方，同时能保证调用方的

服务体验，继续干自己该干的活，不至于被后台性能拖慢。不过需要付出的代价是一致性的减弱，需要接受数据最终一致性；还有就是后台服务一般要 实现幂等性，因为消息

发送出于性能的考虑一般会有重复（保证消息的被收到且仅收到一次对性能是很大的考验）；最后就是必须引入一个独立的broker，如果公司内部没有技术积累，

对broker分布式管理也是一个很大的挑战。

3、如此多的服务，如何实现？

在微服务架构中，一般每一个服务都是有多个拷贝，来做负载均衡。一个服务随时可能下线，也可能应对临时访问压力增加新的服务节点。服务之间如何相互感知？服务如何管理？

这就是服务发现的问题了。一般有两类做法，也各有优缺点。基本都是通过zookeeper等类似技术做服务注册信息的分布式管理。当服务上线时，服务提供者将自己的服务信息

注册到ZK（或类似框架），并通过心跳维持长链接，实时更新链接信息。服务调用者通过ZK寻址，根据可定制算法， 找到一个服务，还可以将服务信息缓存在本地以提高性能。

当服务下线时，ZK会发通知给服务客户端。

客户端做：优点是架构简单，扩展灵活，只对服务注册器依赖。缺点是客户端要维护所有调用服务的地址，有技术难度，一般大公司都有成熟的内部框架支持，比如Dubbo。

服务端做：优点是简单，所有服务对于前台调用方透明，一般在小公司在云服务上部署的应用采用的比较多。

4、服务挂了，如何解决

前面提到，Monolithic方式开发一个很大的风险是，把所有鸡蛋放在一个篮子里，一荣俱荣，一损俱损。而分布式最大的特性就是网络是不可靠的。通过微服务拆分能降低这个风险，

不过如果没有特别的保障，结局肯定是噩梦。所以当我们的系统是由一系列的服务调用链组成的时候，我们必须确保任一环节出问题都不至于影响整体链路。相应的手段有很多：

①重试机制

②限流

③熔断机制

④负载均衡

⑤降级（本地缓存）

这些方法基本都很明确通用，比如Netflix的Hystrix：https://github.com/Netflix/Hystrix

四、参考资料和推荐阅读：

大佬对微服务架构的理解

微服务架构 - 老_张 - 博客园

微服务架构中进行日志采集以及统一处理_aoho的博客-CSDN博客

全链路监控（一）：方案概述与比较 - 掘金