微服务胡言乱语

最新推荐文章于 2024-07-08 16:11:45 发布

Accept3d

最新推荐文章于 2024-07-08 16:11:45 发布

阅读量587

点赞数

本文链接：https://blog.csdn.net/qq_36473502/article/details/103590265

版权

随意总结了一些知识点，内容的逻辑性和正确性可能有较大纰漏。

云服务简介

将it资源作为服务提供给使用者。

云具有按需使用，随处访问，多租户，弹性，可测量的使用和可恢复性的特性

常见的云交付模型有：IaaS,PaaS,SaaS等

DevOps简介

DevOps 是一个完整的面向IT运维的工作流，以 IT 自动化以及持续集成（CI）、持续部署（CD）为基础，来优化程式开发、测试、系统运维等所有环节。

Docker简介

**Docker 属于 Linux 容器的一种封装，提供简单易用的容器使用接口。**它是目前最流行的 Linux 容器解决方案。

Docker 将应用程序与该程序的依赖，打包在一个文件里面。运行这个文件，就会生成一个虚拟容器。程序在这个虚拟容器里运行，就好像在真实的物理机上运行一样。有了 Docker，就不用担心环境问题。

Docker 的主要用途，目前有三大类。

**（1）提供一次性的环境。**比如，本地测试他人的软件、持续集成的时候提供单元测试和构建的环境。

**（2）提供弹性的云服务。**因为 Docker 容器可以随开随关，很适合动态扩容和缩容。

**（3）组建微服务架构。**通过多个容器，一台机器可以跑多个服务，因此在本机就可以模拟出微服务架构。

Kubernetes简介

Kubernetes最初源于谷歌内部的Borg，提供了面向应用的容器集群部署和管理系统。Kubernetes的目标旨在消除编排物理/虚拟计算，网络和存储基础设施的负担，并使应用程序运营商和开发人员完全将重点放在以容器为中心的原语上进行自助运营。Kubernetes 也提供稳定、兼容的基础（平台），用于构建定制化的workflows 和更高级的自动化任务。 Kubernetes 具备完善的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建负载均衡器、故障发现和自我修复能力、服务滚动升级和在线扩容、可扩展的资源自动调度机制、多粒度的资源配额管理能力。 Kubernetes 还提供完善的管理工具，涵盖开发、部署测试、运维监控等各个环节。

Kubernetes架构如下：

Kubernetes架构

Kubernetes主要由以下几个核心组件组成：

etcd保存了整个集群的状态；
apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；
controller manager负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
scheduler负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；
kubelet负责维护容器的生命周期，同时也负责Volume（CSI）和网络（CNI）的管理；
Container runtime负责镜像管理以及Pod和容器的真正运行（CRI）；
kube-proxy负责为Service提供cluster内部的服务发现和负载均衡；

除了核心组件，还有一些推荐的插件，其中有的已经成为CNCF中的托管项目：

CoreDNS负责为整个集群提供DNS服务
Ingress Controller为服务提供外网入口
Prometheus提供资源监控
Dashboard提供GUI
Federation提供跨可用区的集群

为什么需要微服务

传统单体式应用内，每一个业务功能是不可分割的，每个业务模块对于硬件资源的利用并不相同，无形中会有大量的资源浪费的现象。
随着新需求的不断增加，单体式应用的更新和修复变得越来越困难。
随着容器化技术和云服务的不断发展，微服务的可行性越来越高。

什么是微服务

微服务是一种用于构建应用的架构方案。微服务架构有别于更为传统的单体式方案，可将应用拆分成多个核心功能。每个功能都被称为一项服务，可以单独构建和部署，这意味着各项服务在工作（和出现故障）时不会相互影响。

与单体式应用程序的对比

单体应用架构结构简单, 适合于大多数应用场景, 但是单体应用架构存在几点不足:第一, 所有的功能在一个项目上面进行维护, 系统依赖资源包多且复杂;第二, 模块耦合度过高, 一个小问题导致整个应用瘫痪;第三, 应用构建时间长, 任何小修改必须重新构建整个项目;第四, 单体应用的扩展性不高, 无法满足高并发情况下的业务需求;即便是需要扩展也要整个应用复制到不同服务器上面, 并配置负载均衡;另外, 每个业务模块对于硬件资源的利用并不相同, 在单体应用中, 在业务横向扩展时, 整个应用被整体打包部署, 无法根据不同的硬件资源消耗进行单独的调配。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DIikMjYu-1576607663544)(C:\Users\lz\AppData\Roaming\Typora\typora-user-images\image-20191106093824528.png)]

微服务的安全性

在单体式架构中，由于运行应用程序的运行时环境相对隔离，所以治理和安全保护很简单。微服务架构具有典型的革新特征，给活动的治理和应用程序的安全威胁保护带来了更多挑战。

架构的安全性

微服务架构通过定义分布式特征来获得灵活性，系统中的服务能够以分散方式独立开发和部署。从安全角度讲，这种开放架构的一个缺陷是，系统现在更脆弱，因为攻击面增加了。开放的端口更多，API 是公开的，而且安全保护变得更复杂，因为需要在多个位置执行安全保护。

微服务安全设计原则

微服务安全是在实际应用中的一个很普遍要求，安全主要关心调用者是谁， 调用者能干什么，以及如何传播这个信息，也就是常说的服务间的认证和授权。

原则：

单点登录：微服务架构下，实现用户只需要登录一次就能访问所有相互信任的应用系统。-
无状态：前后端分离，后端不保存用户Session，每次请求都要鉴权。
细粒度：每个组件管理自己的功能权限，需要实先确定好权限。
非浏览器客户端的操作性：需要考虑到那些非浏览器端的客户请求，对其提供良好的支持

微服务常见认证/授权方案

分布式Session

传统的单体应用的session，在Spring cloud微服务架构下，可以采用分布式session机制，可以将用户的认证信息存储在共享存储（如redis）中，用户会话作为key实现简单的分布式哈希映射，当用户访问微服务时，用户数据可以从共享存储中获取。Spring Session对分布式Session提供了支持，也与Spring Boot/Cloud无缝集成。

API Tokens

基于Token认证的典型流程：

用户使用包含用户名和密码的credential从客户端发起资源请求。
后端接受请求，通过授权中心，生产有效token字符串，返回给客户端。
客户端获得token后，再次发出资源请求。
后端接受带token的请求，通过授权中心，获取相关资源，返回给客户端。

优点：

服务端无状态：服务端不需要存储Session，因为Token已携带用户的相关信息
性能好：校验Token不需要访问远程服务或数据库
支持移动端
支持跨程序、跨域调用

缺点：

每次用户请求需要携带有效token，与Auth服务进行交互验证
Auth服务可能需要处理大量的生产token的操作，可能存在性能问题

Token可采用 JSON Web Tokens（JWT）等协议来生成。

OAuth2.0

过程如下:

OAuth运行流程

用户打开客户端以后，客户端要求用户给予授权。
用户同意给予客户端授权。
客户端使用上一步获得的授权，向认证服务器申请令牌。
认证服务器对客户端进行认证以后，确认无误，同意发放令牌。
客户端使用令牌，向资源服务器申请获取资源。
资源服务器确认令牌无误，同意向客户端开放资源。

OAuth 2.0定义了四种授权方式。

授权码模式（authorization code）
简化模式（implicit）
密码模式（resource owner password credentials）
客户端模式（client credentials）

具体细节可参考理解Oauth2.0

微服务间的通信

RESTful

RESTful是目前最流行的 API 设计规范，用于 Web 数据接口的设计。

RESTful的思想是将服务器提供的信息(如文本,图片甚至服务)作为资源，并且将五种HTTP方法作为动词，客户端通过"动词+宾语"的形式来对资源进行CRUD操作。

五种HTTP方法如下。

GET：读取（Read）
POST：新建（Create）
PUT：更新（Update）
PATCH：更新（Update），通常是部分更新
DELETE：删除（Delete）

更多设计规范可以参考RESTful API的最佳实践

gRPC

RPC是指远程过程调用，也就是说两台服务器A，B，一个应用部署在A服务器上，想要调用B服务器上应用提供的函数/方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。

gRPC 是由 google 开发，是一款语言中立、平台中立、开源的远程过程调用(RPC)系统。

在 gRPC 里客户端应用可以像调用本地对象一样直接调用另一台不同的机器上服务端应用的方法，使得您能够更容易地创建分布式应用和服务。与许多 RPC 系统类似，gRPC 也是基于以下理念：定义一个服务，指定其能够被远程调用的方法（包含参数和返回类型）。在服务端实现这个接口，并运行一个 gRPC 服务器来处理客户端调用。在客户端拥有一个存根能够像服务端一样的方法。

gRPC有以下特点:

基于HTTP/2

HTTP/2 提供了连接多路复用、双向流、服务器推送、请求优先级、首部压缩等机制。可以节省带宽、降低TCP链接次数、节省CPU，帮助移动设备延长电池寿命等。gRPC 的协议设计上使用了HTTP2 现有的语义，请求和响应的数据使用HTTP Body 发送，其他的控制信息则用Header 表示。

IDL使用ProtoBuf

gRPC使用ProtoBuf来定义服务，ProtoBuf是由Google开发的一种数据序列化协议（类似于XML、JSON、hessian）。ProtoBuf能够将数据进行序列化，并广泛应用在数据存储、通信协议等方面。压缩和传输效率高，语法简单，表达力强。

多语言支持

gRPC支持多种语言（C, C++, Python, PHP, Nodejs, C#, Objective-C、Golang、Java），并能够基于语言自动生成客户端和服务端功能库。目前已提供了C版本grpc、Java版本grpc-java 和 Go版本grpc-go，其它语言的版本正在积极开发中，其中，grpc支持C、C++、Node.js、Python、Ruby、Objective-C、PHP和C#等语言，grpc-java已经支持Android开发。