微服务架构--分布式架构与微服务介绍相关概念以及典型解决方案

本文链接：https://blog.youkuaiyun.com/maoguqi/article/details/133206351

微服务架构

微服务架构

什么是微服务架构

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值

每个服务运行在其独立的进程中，互不影响。
服务与服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 协议的 RESTful API）。
每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。
- 对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

为什么需要微服务架构

微服务架构是从soa架构模式演变过来的，比SOA架构对服务拆分的粒度更加精细，让业务界限更加清晰

SOA 早期均使用了总线模式，这种总线模式是与某种技术栈强绑定的，比如：J2EE。这导致很多企业的遗留系统很难对接，切换时间太长，成本太高，新系统稳定性的收敛也需要一些时间，最终 SOA 看起来很美，但却成为了企业级奢侈品，中小公司都望而生畏。
此外，实施SOA时会遇到很多问题，比如通信协议（例如SOAP）的选择、第三方中间件如何选择、服务粒度如何确定等，目前也存在一些关于如何划分系统的指导性原则，但其中有很多都是错误的。SOA并没有告诉你如何将单体应用划分成微服务，所以在实施SOA时会遇到很多问题。

传统企业或者很多企业的软件，大多不止一套系统，都是各个独立大系统的堆砌。通常存在扩展性差、可靠性不高、维护成本大、重复轮子很多等问题。

对于上述这些问题，可以想到的解决方案有：组件化、服务化。

微服务架构将各个组件或者模块分散到各个服务中，对整个系统实现解耦。那微服务架构强调的重中之重就是业务系统需要完善的组件化和服务化。

组件化：将一个大系统，按照一定的业务或者技术维度关注形式，拆分成独立的组件。
- 目的是为了分而治之，为了可重用，为了减少耦合度。
- 比如按照技术维度：搜索组件、缓存组件；按照业务维度：用户中心、支付中心等
服务化：是一种以服务为中心的解决方案：服务注册、服务发布、服务调用、服务监控、服务负载均衡等。
- 核心就是不同服务之间的通信。
- 服务化之前：代码重复、可维护性低、DB 访问耦合等
- 服务化后的好处：调用简单、代码复用、业务隔离、数据库解耦等

微服务优点

技术异构性：

不同服务内部的开发技术可以不一致，你可以用java来开发helloworld服务A，用golang来开发helloworld服务B。

为不同的服务选择最适合该服务的技术，系统中不同部分也可以使用不同的存储技术，比如A服务可以选择redis存储，B服务你可以选择用MySQL存储，这都是允许的。

隔离性：

一个服务不可用不会导致另一个服务也瘫痪，因为各个服务是相互独立和自治的系统。

这在单体应用程序中是做不到的，单体应用程序中某个模块瘫痪，必将导致整个系统不可用，当然，单体程序也可以在不同机器上部署同样的程序来实现备份，不过，同样存在资源浪费问题。

可扩展性：

可以只对那些影响性能的服务做扩展升级，这样对症下药的效果是很好的。

庞大的单体服务如果出现性能瓶颈只能对软件整体进行扩展，可能真正影响性能的只是其中一个很小的模块，我们也不得不付出升级整个应用的代价，这在微服务架构中得到了改善。

简化部署：

在微服务架构中，各个服务的部署是独立的，如果真出了问题也只是影响单个服务，可以快速回滚版本解决。

如果你的服务是一个超大的单体服务，有几百万行代码，即使修改了几行代码也要重新编译整个应用，这显然是非常繁琐的，而且软件变更带来的不确定性非常高，软件部署的影响也非常大。

易优化：

微服务架构中单个服务的代码量不会很大，这样当你需要重构或者优化这部分服务的时候，就会容易很多，毕竟，代码量越少意味着代码改动带来的影响越可控。

微服务架构存在的问题

服务注册与发现：

微服务之间相互调用完成整体业务功能，需要考虑如何在众多微服务中找到正确的目标服务地址。这就是所谓「服务发现」功能，常用的做法是：

服务提供方启动的时候把自己的地址上报给「服务注册中心」，这就是「服务注册」。
服务调用方「订阅」服务变更「通知」，动态的接收服务注册中心推送的服务地址列表，以后想找哪个服务直接发给他就可以。
分布式服务注册与发现（eureka、consul、zookeeper、Nacos）
分布式事务解决方案（rabbitmq、rocketmq事务消息、lnc（淘汰）、setata）最终一致性概念
分布式任务调度平台（XXL-Job、AlibabaCloud Scheduler、elastic-job）

运维成本：

微服务将系统分成多个独立的部分，每个部分都是可以独立部署的业务单元。这就意味着，在微服务架构下，随着服务数量的增多，每个服务都需要独立的配置、部署、监控、日志收集等，因此成本呈指数级增长。

这就需要我们有一套完备的服务监控体系，包括拓扑关系、监控（Metrics）、日志监控（Logging）、调用追踪（Trace）、告警通知、健康检查等，防患于未然。
分布式日志采集系统elk+kafka
分布式服务追踪与调用链系统Zipkin

部署自动化：

对于微服务架构而言，每个服务都是一个独立可部署的业务单元，每个服务的修改都需要独立部署。如何有效地构建自动化部署流水线，降低部署成本、提高部署频率，是微服务架构下需要面临的一个挑战。

分布式服务配置中心（springcloud config/nacos/disconfig/携程阿波罗）

服务容错：

生产环境复杂多变，服务运行过程中不可避免的发生各种故障（宕机、过载等等），需要引入「熔断、隔离、限流和降级、超时机制」等「服务容错」机制来保证服务持续可用性。

微服务是拆分成多个服务进行部署，服务间的通信都是通过网络，此时的性能会受影响。同时可靠性也会受影响。数据一致性也需要严格控制，其成本也比单块系统高。

服务治理：

由于微服务架构是把系统拆分为若干个可独立部署的服务，所以需要：

进行服务间的依赖测试：在服务数量较多的情况下，如何有效地保证服务之间能有效按照接口的约定正常工作，成为微服务实施过程中必须面临的巨大挑战。
随着微服务个数的增多，如何清晰有效地展示服务之间的依赖关系，成为了一个挑战。

服务安全：

有些服务的敏感数据存在安全问题，「服务安全」就是对敏感服务采用安全鉴权机制，对服务的访问需要进行相应的身份验证和授权，防止数据泄露的风险。

DevOps 与组织结构：

传统单块架构中，团队通常是按技能划分，如开发部、测试部、运维部，并通过项目的方式协作，完成系统交付。而在微服务架构的实施过程中，在组织或者团队层面，如何传递 DevOps 文化的价值，让团队理解 DevOps 文化的价值，并构建全功能团队，也是一个不小的挑战。

微服务不仅表现出一种架构模型，同样也表现出一种组织模型。
这种新型的组织模型意味着开发人员和运维的角色发生了变化，开发者将承担起服务整个生命周期的责任，包括部署和监控，而运维也越来越多地表现出一种顾问式的角色，尽早考虑服务如何部署。
因此，如何在微服务的实施中，按需调整组织架构，构建全功能的团队，是一个不小的挑战。

常见的微服务框架

Dubbo

Dubbo是阿里巴巴开源的基于 Java 的高性能 RPC（一种远程调用）分布式服务框架（SOA），致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。

Dubbo 提供的基础能力包括：服务发现、流式通信、负载均衡、流量治理等等。

提供的通信模型：同步的 Request-Response （默认）、消费端异步请求、提供端异步执行、消费端请求流、提供端响应流、双向流式通信。

Dubbo 提供的是 Client-Based 的服务发现机制，使用者可以有多种方式启用服务发现：

使用独立的注册中心组件，如 Nacos、Zookeeper、Consul、Etcd 等。
将服务的组织与注册交给底层容器平台，如 Kubernetes。

部署架构：为了在分布式环境下实现各个微服务组件间的协作， Dubbo 定义了一些中心化组件。

注册中心
配置中心
元数据中心

dubbo

Tars

腾讯内部使用的微服务架构 TAF（Total Application Framework）多年的实践成果总结而成的开源项目。

仅支持 C++ 语言，目前在腾讯内部应用也非常广泛。2017 年对外开源，仅支持 C++ 语言。

Tars

gRPC

是Google开发的高性能、通用的开源RPC框架，其由Google主要面向移动应用开发并基于HTTP/2协议标准而设计，基于ProtoBuf(Protocol Buffers)序列化协议开发。

本身它不是分布式的，所以要实现上面的框架的功能需要进一步的开发。2015 年对外开源的跨语言 RPC 框架，支持多种语言。

gRPC

thrift

最初是由 Facebook 开发的内部系统跨语言的高性能 RPC 框架，2007 年贡献给了 Apache 基金，成为 Apache 开源项目之一，跟 gRPC 一样，Thrift 也有一套自己的接口定义语言 IDL，可以通过代码生成器，生成各种编程语言的 Client 端和 Server 端的 SDK 代码，支持多种语言。

微服务框架与RPC

什么是RPC？

RPC (Remote Procedure Call）远程过程调用是一个计算机通信协议。我们一般的程序调用是本地程序内部的调用，RPC允许你像调用本地函数一样去调用另一个程序的函数，这中间会涉及网络通信和进程间通信，但你无需知道实现细节，RPC框架为你屏蔽了底层实现。

RPC是一种服务器-客户端（Client/Server）模式，经典实现是一个通过发送请求-接受回应进行信息交互的系统。

两者关系：

微服务框架一般都包含了RPC的实现和一系列「服务治理」能力，是一套软件开发框架。

我们可以基于这个框架之上实现自己的微服务，方便的利用微服务框架提供的「服务治理」能力和RPC能力，所以微服务框架也被有些人称作RPC框架。

微服务与SOA的关系

微服务可以说是 SOA 的一种，但两者之间存在一些差异：

通讯协议：微服务架构基于SOA架构，继承了SOA架构优点，在微服务架构中去除SOA架构中SOAP协议和ESB企业服务总线，改为http+json形式传输接口。
服务拆分：微服务架构比SOA架构的粒度更加精细，提倡让专业的人去做专业的事。每个服务互不影响。每个服务都是单独独立数据库、redis连接、MQ等。并且都是独立部署，整个服务架构更加轻巧。
迭代：微服务的架构模式比SOA架构模式，更加适合敏捷、高效、快速迭代。