# learn-IAM

**Repository Path**: fcourage/learn-iam

## Basic Information

- **Project Name**: learn-IAM
- **Description**: No description available
- **Primary Language**: Unknown
- **License**: MIT
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2021-11-30
- **Last Updated**: 2021-11-30

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# learn iam
## IAM系统概述
* IAM（Identity and Access Management，身份识别与访问管理）系统是用 Go 语言编写的一个 Web 服务，用于给第三方用户提供访问控制服务。
    * 对访问进行认证
    * 对资源进行授权
![IAM 系统的完整架构](https://static001.geekbang.org/resource/image/0a/42/0a5f6fd67af1eda1c690c8216dc5e042.jpg?wh=3197*2063)
![组件和功能](https://static001.geekbang.org/resource/image/6c/71/6cdbde36255c7fb2d4f2e718c9077a71.jpeg?wh=1920*1043)
* IAM 系统的资源授权的流程
    ![资源授权的流程](https://static001.geekbang.org/resource/image/ee/50/eed75fcd91d6e726ca74315d65193150.jpg?wh=2513*1134)
    1. 用户需要提供昵称、密码、邮箱、电话等信息注册并登录到 IAM 系统，这里是以用户名和密码作为唯一的身份标识来访问 IAM 系统，并且完成认证。
    2. 因为访问 IAM 的资源授权接口是通过密钥（secretID/secretKey）的方式进行认证的，所以用户需要在 IAM 中创建属于自己的密钥资源。
    3. 因为 IAM 通过授权策略完成授权，所以用户需要在 IAM 中创建授权策略。
    4. 请求 IAM 提供的授权接口，IAM 会根据用户的请求内容和授权策略来决定一个授权请求是否被允许。
* 3 种 RESTful 资源
    * 用户（User）：实现对用户的增、删、改、查、修改密码、批量修改等操作。
    * 密钥（Secret）：实现对密钥的增、删、改、查操作。
    * 策略（Policy）：实现对策略的增、删、改、查、批量删除操作。
* IAM 软件架构模式:前后端分离架构
![前后端分离架构](https://static001.geekbang.org/resource/image/a2/76/a2e1f1cc135debd86611yya1f221c476.jpg?wh=2519*1447)
#### 环境准备
* 配置一个 Go 开发环境，我们可以通过以下 4 步实现：
    1. Linux 服务器申请和配置
    2. 依赖安装和配置Go 
    3. 编译环境安装和配置Go 
    4. 开发 IDE 安装和配置
#### 项目部署：如何快速部署 IAM 系统
[IAM 部署指南](https://github.com/marmotedu/iam/blob/master/docs/guide/zh-CN/installation/README.md)
## 规范设计
#### 如何规范
* 非编码类规范
    1. 开源规范
        * [开源规范详细列表](https://github.com/marmotedu/geekbang-go/blob/master/%E5%BC%80%E6%BA%90%E8%A7%84%E8%8C%83%E8%AF%A6%E7%BB%86%E5%88%97%E8%A1%A8.md)
    2. 文档规范
        * README 规范
            ```
            # 项目名称

            <!-- 写一段简短的话描述项目 -->

            ## 功能特性

            <!-- 描述该项目的核心功能点 -->

            ## 软件架构(可选)

            <!-- 可以描述下项目的架构 -->

            ## 快速开始

            ### 依赖检查

            <!-- 描述该项目的依赖，比如依赖的包、工具或者其他任何依赖项 -->

            ### 构建

            <!-- 描述如何构建该项目 -->

            ### 运行

            <!-- 描述如何运行该项目 -->

            ## 使用指南

            <!-- 描述如何使用该项目 -->

            ## 如何贡献

            <!-- 告诉其他开发者如果给该项目贡献源码 -->

            ## 社区(可选)

            <!-- 如果有需要可以介绍一些社区相关的内容 -->

            ## 关于作者

            <!-- 这里写上项目作者 -->

            ## 谁在用(可选)

            <!-- 可以列出使用本项目的其他有影响力的项目，算是给项目打个广告吧 -->

            ## 许可证

            <!-- 这里链接上该项目的开源许可证 -->
            ```
            在线的 README 生成工具，可以参考下：[readme.so](https://readme.so/)。
        * 项目文档规范
            * 开发文档：用来说明项目的开发流程，比如如何搭建开发环境、构建二进制文件、测试、部署等。
            * 用户文档：软件的使用文档，对象一般是软件的使用者，内容可根据需要添加。比如，可以包括 API 文档、SDK 文档、安装文档、功能介绍文档、最佳实践、操作指南、常见问题等。
        * API 接口文档规范
            * 接口描述：描述接口实现了什么功能。
            * 请求方法：接口的请求方法，格式为 HTTP 方法 请求路径，例如 POST /v1/users。在 通用说明中的请求方法部分，会说明接口的请求协议和请求地址。
            * 输入参数：接口的输入字段，它又分为 Header 参数、Query 参数、Body 参数、Path 参数。每个字段通过：参数名称、必选、类型 和 描述 4 个属性来描述。如果参数有限制或者默认值，可以在描述部分注明。
            * 输出参数：接口的返回字段，每个字段通过 参数名称、类型 和 描述 3 个属性来描述。
            * 请求示例：一个真实的 API 接口请求和返回示例。
    3. 版本规范
        * 语义化版本格式为：主版本号.次版本号.修订号（X.Y.Z），其中 X、Y 和 Z 为非负的整数，且禁止在数字前方补零。
        * 如何确定版本号？
            1. 在实际开发的时候，我建议你使用 0.1.0 作为第一个开发版本号，并在后续的每次发行时递增次版本号。
            2. 当我们的版本是一个稳定的版本，并且第一次对外发布时，版本号可以定为 1.0.0。
            3. 当我们严格按照 Angular commit message 规范提交代码时，版本号可以这么来确定：
                * fix 类型的 commit 可以将修订号 +1。
                * feat 类型的 commit 可以将次版本号 +1。
                * 带有 BREAKING CHANGE 的 commit 可以将主版本号 +1。
    4. Commit 规范
        * 符合 Angular 规范的 Commit Message
            ```
            <type>[optional scope]: <description>
            // 空行
            [optional body]
            // 空行
            [optional footer(s)]
            ```
            其中，Header 是必需的，Body 和 Footer 可以省略。在以上规范中，必须用括号 () 括起来， [] 后必须紧跟冒号 ，冒号后必须紧跟空格，2 个空行也是必需的。
            ![常见 type 和它们所属的类别](https://static001.geekbang.org/resource/image/89/27/89c618a7415c0c38b09d86d7f882a427.png?wh=726*511)
        * 提交频率
            1. 对项目进行了修改，一通过测试就立即 commit
            2. 定时提交
        * 合并提交
            1. 新建一个分支用于开发新功能
                `git checkout -b feature/user`
            2. 合并所有 commit， 
                `git rebase -i <commit ID>`
            3. 将 feature 分支 feature/user 的改动合并到主干分支
                ```
                $ git checkout master
                $ git merge feature/user
                $ git log --oneline
                ```
        * 修改 Commit Message
            1. git commit --amend：修改最近一次 commit 的 message；
            2. git rebase -i：修改某次 commit 的 message。
            ```
            Commit Message 是 commit 数据结构中的一个属性，如果 Commit Message 有变更，则 commit ID 一定会变，git commit --amend 只会变更最近一次的 commit ID，但是 git rebase -i 会变更父 commit ID 之后所有提交的 commit ID。
            如果当前分支有未 commit 的代码，需要先执行 git stash 将工作状态进行暂存，当修改完成后再执行 git stash pop 恢复之前的工作状态。
            ```
        * 自动化规范commit提交程序
    5. 发布规范
* 编码类规范
    1. 目录规范
        * 如何规范目录？
            1. 命名清晰
            2. 功能明确
            3. 全面性
            4. 可预测性
            5. 可扩展性
    2. 代码规范
    3. 接口规范
    4. 日志规范
    5. 错误码规范