亲历的企业级微服务的完整构建过程-系列文章目录
本人参与了这次的企业级微服务的完整构建,想要记录下来以便以后复习,同时也想分享给小伙伴们,抛砖引玉,欢迎大家提出自己的意见和建议,大家一起探讨一起成长。以下为该系列所有文章的链接:
- 搭建和使用Maven私有仓库(Nexus)(更新中。。。)
- API网关(待发布)
- 认证中心(待发布)
- Redis框架(待发布)
- RabbitMQ(待发布)
- MyBatis(待发布)
- Web模块(待发布)
- 低代码(待发布)
- Core
- 监控和告警(待发布)
- MongoDB(待发布)
搭建和使用Maven私有仓库(Nexus)-系列文章目录
说明:
- 以下部分模块,绝大多数人,在日常工作中都是用不到的,所以我就没有介绍,毕竟时间是最重要的成本,没必要花大量时间在我们用不到的内容上。
- 下面的“1 通用”章节,系列文章中的每一篇内容都相同,介绍一些背景、约定和官网链接等,大家只要知道这些内容了,就不用每篇文章都去看了。
- 安装步骤
- 登录和界面
- 备份和恢复
- 管理:讲述了Nexus的管理功能,包括用户管理、权限管理、任务管理等
- 使用Nexus仓库:讲述了使用(而非管理) Nexus Repository 的方方面面的知识
- 仓库管理器概念:使用 Nexus 需要先理解一些概念,该节内容提供了必要的背景和知识
- 用户界面概述
- 搜索组件(暂时用不到,略)
- 浏览仓库和仓库组
- 管理当前登录用户的资料
- 上传组件
- 查看标签(仅可用于Pro版本,略)
- 集成(主要讲述了如何使用 APIs 和 集成外部工具)(暂时用不到,略)
- Maven中配置和使用Nexus
正文
1 通用
1.1 前言
在构建微服务之前,需要先做一些准备工作,比如Maven私有仓库的管理。因为有些微服务模块是作为公共组件被其他微服务引用的,这些公共的微服务,就要设置为依赖,并用Maven仓库管理起来,将自定义的依赖上传到Maven中央仓库并不是一个明智的选择。原因有3个:
- 最重要的是隐私和安全问题,我们不可能把企业内部开发的组件上传到公共网络,让所有人能够随便下载;
- 上传很麻烦,上传方法详见 https://blog.csdn.net/agonie201218/article/details/124800163;
- 可能不允许上外网,则无法上传;
- 可能会有网络延迟、上传缓慢的问题。
- 降低了中央仓库的负担。
综上,我们最好是搭建自己的私有Maven仓库,而当前最流行的就是 Sonatype Nexus Repository Manager
,以下简称 Nexus
。
1.2 约定
- 我使用的版本是
OSS 3.40.1-01
,整个系列的文章都是在该版本上展开介绍,你们可能使用的是 Pro 版,少数模块是我的 OSS 版上没有的。不过一般使用的话,OSS 版已经够用了 - 文中出现的
Repository
,中文称之为“仓库” - 文中出现的变量
$install-dir
,值为/opt/sonatype/nexus
- 文中出现的变量
$data-dir
,值为/opt/sonatype/sonatype-work/nexus3
,或/nexus-data
,两者都是在docker容器nexus中的路径,一个是软链接,一个是实际路径 - 文中出现的变量
${jetty.etc}
,值为/opt/sonatype/nexus/etc/jetty
- NXRM:Nexus Repository Manager,即 Nexus 仓库管理器
- RBAC:Role-Based Access Control,即 基于角色的访问控制
1.3 官方文档
提供Nexus的官方文档:https://help.sonatype.com/repomanager3/
官方文档包含了系统要求、搭建方法,以及各种操作方法等,内容已经非常全面了。
2 访问控制
Nexus Repository 使用基于角色的访问控制(RBAC)来赋予管理员细粒度的用户权限控制:
- 对 Nexus Repository 网络应用程序的访问
- 对仓库中组件路径的读访问
- 对配置模块的管理员访问
- 发布或上传文件到一个仓库
默认配置附带了 Administrator
角色和可选的匿名访问(Anonymous Access),来浏览和读取所有仓库。当需要创建一个受保护的仓库时,我们不应该使用默认的 Anonomous
角色。Nexus Repository 提供了一个能适应任何场景的安全模型。
注:默认的 Administrator
角色提供了 Nexus Repository 系统的所有方面的权限,并且默认分配给了用户 admin
。admin
的初始密码可以在 Nexus 启动后,在 $data-dir/admin.password
文件中找到。注意:一旦修改了初始密码,$data-dir/admin.password
文件会自动被删除。
RBAC 遵循“最小权限”(Least Privilege)原则,该原则基于完成工作需要访问的功能,给予用户最少的访问权限。Nexus Repository内部创建的角色,可以被加入到外部角色和组,该外部角色和组被你的组织的目录服务所管理。将角色的分配委托给外部系统,极大减少了新用户入职/离职的开销成本。
以下是一个新的团队入职的例子:
“Apollo”开发团队需要一个托管仓库“dev-apollo”的访问权限。团队成员们被分配到公司活动目录(Active Directory)的组中。
仓库管理员创建了一个新的角色“team-apollo”,并在活动目录中,将它分配给“Apollo”组。
admin
用户给该角色添加了那个仓库的browse
,read
和 write
的权限:
- nx-repository-view-maven2-dev-apollo-add
- nx-repository-view-maven2-dev-apollo-read
- nx-repository-view-maven2-dev-apollo-browse
在活动目录中,团队成员们被添加进或移出“Apollo”组。
注:
对 Nexus Repository 的使用权是授予的,不是撤销的。某个权限允许的访问,不能被另一个权限收回。因此,最佳实践是仅仅提供一个团队需要的资源的使用权。从长远来看,使用通配符权限(使用 *
)可能并不可取,因为这需要相当大的精力去审计和回退。
下面先简单介绍下 Nexus 中的一些概念:
-
领域(Realms)
RBAC 系统需要不同的认证和授权系统提供支持。 -
权限(Privileges)
权限是和 Nexus Repository 的功能进行交互的各个层级的权利。仓库管理器附带了一组不可修改的核心权限。新的仓库在创建时,自动添加了一些权限。 -
角色(Roles)
权限可以被分组伟角色,一遍更容易为用户定义通用的访问模式。为了更加容易地通过相似的权限组来管理用户,我们使用角色,而不是分配单独的权限给单独的用户。 -
用户(Users)
用户可以被直接添加和管理,而不必使用外部的领域。用户可以被分配给一个或多个角色,也可以直接被分配权限。 -
内容选择器(Content Selectors)
我们可以使用内容选择器来配置特定命名空间或仓库位置的访问权。内容选择器被添加到自定义权限上,从而给那些资源授予访问权。 -
默认角色(Default Role)
默认角色能力可以被用来分配一个通用权限组给所有已认证的用户。这对于“允许组织中每个人有一个标准级别的访问权”很有用(注意是能够通过你配置的Realms
进行认证的每个人)。