micro-services

发表于 更新于 分类于 阅读次数： 本文字数： 4.7k 阅读时长 ≈ 4 分钟

项目工程化、微服务相关介绍

项目工程化

  • 开源规范

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    # 开源协议
      1. GPL - General Public License
        > 衍生代码的分发需要开源并且也要遵守此协议
      2. MPL
        > 允许免费重发布、免费修改，但要求修改的代码版权归软件发起者，这种授权维护了商业软件的利益，要求基于这种软件的修改无偿贡献版权给该软件
      3. LGPL
      4. Apache
        > Apache 2.0协议除了为用户提供版权许可之外，还有专利许可，适合设计专利内容的项目
      5. BSD
        >
      6. MIT
        > MIT 协议是所有开源许可中最宽松的一个，除了细笔包含许可声明之外，再无任何限制

  • 开源规范

    1
    2
    3
    4
    5
    6
    7
    8
    1. 项目结构:
    2. 严格遵循代码规范:
    3. 代码质量:
    4. 单元测试覆盖率:
    5. 版本发布规范:
    6. 向下兼容:
    7. 详细的文档说明:
    8. 安全:

  • 文档规范

    1
    2
    3
    4
    5
    6
    1. README文档
      介绍项目功能、安装、部署、使用
    2. 项目文档
      开发文档: 说明项目的开发流程
      用户文档:
    3. API接口文档

  • 版本规范

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    语义化版本规范: SemVer: 主版本号.次版本号.修订号 (X.Y.Z), XYZ为非负的整数，禁止在数字前方补零
      主版本号: MAJOR: 当做了不兼容API修改
      次版本号: MINOR: 当做了向下兼容的功能新增及修改 -- 偶数为稳定版本，奇数为开发版本
      修订号:PATCH: 向下兼容问题修正

    X.Y.Z[-先行版本号][+版本编译元数据]

    1. 实际开发的时候，使用0.1.0作为第一开发版本号
    fix类型的commit 可以将修订号+1
    feat类型的commit可以将次版本号+1
    breaking change的commit将主版本号+1

  • Commit 规范

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    Commit Message包含三部分:
      Header: <type>[optional scope]: <description>
        type:
          feat: 新增功能
          fix: Bug修复
          perf: 提高代码性能的变更
          style: 代码格式类的变更
          refactor: 其他代码类的变更，这些变更不属于feat,fix,perf和style. 简化代码，重命名变量、删除冗余代码
          test: 新增测试用例或是更新现有测试用例
          ci: 持续集成和部署想干改动，
          docs: 文档类更新
          chore: 其他类型，构建流程、依赖管理或者辅助工具的变动

        scope:

        description: 动词开头，使用现在时

      Body:

      Footer:

    git rebase: 重写历史
      git rebase -i <commit ID> 这里是需要合并commit中最旧commit的父commit ID

    git reset HEAD~3A 撤销过去的commit,重新提交

    git commit --amend: 修改最近一次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恢复之前的工作状态

  • 目录结构设计

    1
    2
    3
    4
    5
    6
    # 结构化目录结构
      /cmd            -- 组件
      /internal       -- 私有应用和库代码,不希望在其他应用和库中被导入
      /pkg            -- 存放可以被外部应用使用的代码库
    # 平铺式目录结构
      > 这种方式在很多框架/库中存在,好处式引用路径长度短

  • 工作流设计

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    # 集中式工作流
      > 适用于团队人数少、开发不频繁、不需要同时维护多个版本的小项目

    # 功能分支工作流
      > 不同功能在不同的分支进行开发，最后合并到master分支
      Merge pull request:
        1. Create a merge commit: git merge --no-ff. feature分支上所有的commit都会加到master分支上，并且会生成一个merge commit。
        2. Squash and merge: git merge --squash. feature分支上所有的commit都合并成一个commit.然后加到master分支,原来的commit历史会丢失
        3. Rebase and merge: git rebase. 将pull request上所有提交历史按照原有顺序依次添加到master分支的头部HEAD.

    # Git Flow工作流
      > 比较适合大型的项目或者迭代速度快的项目
      master: 该分支最新代码是发布状态，不能直接在该分支上开发，master分支每合并一个hotfix/release分支，都会打一个版本标签
      develop: 该分支是开发中的最新代码，该分支只做合并操作，不能直接在该分支上开发
      feature: 功能开发,基于develop分支新建一个feature分支，feature分支合并之前先pull一下develop分支，
      release: 在发布阶段作为版本发布的预发布分支，基于develop分支创建, 测试通过后，将release分支合并到master和develop，并在master分支上版本标签，最后删除release版本分支
      hotfix: 在维护阶段做紧急Bug修复分支，hotfix分支合并到master和develop分支，并在master分支打上修复后的版本标签,最后删除hotfix分支

    # Forking 工作流
      项目远程仓库和开发者远程仓库完全独立，开发者通过Pull Request的方式给远程仓库贡献代码，项目维护者选择性地接收任何开发者的提交，通过这种方式，可以避免开发者项目远程仓库的权限,从而提高项目远程仓库的安全性

  • 研发流程

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    # 需求阶段
      1. 市场调研 - PDM(Product Manager) 产品经理
      2. 需求分析 - PM(Project Manager) 项目经理
      3. 需求文档 - 最终产物
      4. 需求评审

    # 设计阶段
      1. 交互设计 - UX(User Experience) 交互设计师
      2. 视觉设计 - UI(User Interface) 视觉设计师
      3. 技术设计
      4. 技术评审 - 最终产物
      5. 需求排期

    # 开发阶段
      - 开发 - Makefile - RD(Research and Development engineer) 研发工程师
        1. Git Flow工作流
        2. 生成代码 -- 尽可能自动生成代码
        3. 版权检查
        4. 静态代码检查
        5. 单元测试
        6. 编译
        7. 自测
        8. Code Review
        9. Merge
      - 构建 - CI/CD
        1. 代码扫描
        2. 单元测试
        3. 编译打包
        4. 归档[镜像仓库]

    # 测试阶段
      > 测试阶段为了不阻塞测试，确保项目按时发布，研发人员应该优先解决测试同学的Bug,至少是阻塞类的Bug
      1. 功能测试 - QA(Quality Assurance) 质量管理工程师
      2. 性能测试 - QE(Quality Engineering) 质量工程师
      3. 集成测试
      4. 系统测试

    # 发布阶段
      - 代码发布
        1. 合并到主干 - Master分支
        2. 生成版本号
        3. 打标签
        4. 代码扫描
        5. 单元测试
        6. 编译
        7. 发布构建产物
      - 发布审批
        1. 资源申请
        2. 创建发布计划
        3. 创建发布单
        4. 发布单审批
      - 服务发布
        1. 预发部署
        2. 预发验证
        3. 现网部署
        4. 现网验证

    # 运营阶段
      - 产品运营
        1. 技术沙龙
        2. 技术推文
      - 运维运营 - OP(Operation) 运维工程师
        1. 运维工具
        2. 日志系统
        3. 监控告警

  • 应用生命周期管理

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    # 研发模式
      - 瀑布模式
        - 优点:
          1. 严格按照研发阶段推进研发进度，流程清晰，适合按项目交付的应用
        - 缺点:
          1. 变更困难
          2. 研发周期长
      - 迭代模式
        > 不要求每个阶段的任务做到最完美，而是先把主要功能搭建起来，然后通过客户的反馈信息不断完善
      - 敏捷模式
        > 敏捷模式把一个大的需求分成多个、可分阶段完成的小迭代，每个迭代交付的都是一个可使用的软件，开发过程中，软件要一致处于可使用状态
        - Scrum开发模式

    # CI/CD
      CI: Continuous Integration, 持续集成
      CD: Continous Delivery, 持续交付
      CD: Continous Deployment, 持续部署

    # DevOps: 研发运维一体化
      - AIOps: 职能运维
      - ChatOps: 通过聊天窗口的机器人Bot出发任务
      - GitOps:
        > 开发人员开发完代码后推送Git仓库，触发CI流程，CI流程通过编译构建出Docker镜像，并将镜像push到Docker镜像仓库，Push动作触发Push事件，通过webhook形式通知Config Updater服务，Config Updater服务从镜像仓库中下载镜像，并更新Git仓库中的kubernetes YAML文件
      - NoOps:

介绍Web框架

  • Gin

    Go编写的web框架，是一个类似martini性能更好的API框架

    1
    2
    3
    4
    5
    6
    7
    8
    1. Engine: 初始化gin对象实例，
      日志
      中间件
      路由控制
      handlercontext
    2. Router: 定义各种路由规则和条件
    3. Context: 允许在中间件中共享变量，管理整个流程，验证请求的json以及提供
    4. Bind:

介绍微服务架构设计

  • 服务化基础设施技术选型

    • 服务间通信中间件
      • 同步方式: RPC
      • 异步方式: MQ

  • 客户端一致性

    共享相同connection可以在同一个事务里

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    1. begin tx 开启本地事务
    2. do work 执行业务操作
    3. insert message 向同实例消息库插入消息
    4. end tx 事务提交
    5. send message 网络向server发送消息
    6. response server 回应消息
    7. delete message 如果server回复成功则删除消息
    8. scan message 补偿任务扫描未发送消息
    9. send message 补偿任务补偿消息
    10. delete message 补偿任务删除补偿成功的消息

  • 服务端存储模型

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    # Kafka RocketMQ基于partition存储模型
    > 每个subject分为一个或多个partition，而Server收到消息后将其分发到某个partition上，而concumer消费的时候与partition对应。合理的分配策略是partition个数与consumer个数成倍数关系.
    > 静态绑定关系导致consumer扩容缩容比较麻烦
    > 顺序append文件，提供很好的性能
    > 顺序消费文件，使用offset表示消费进度，不给给个消息记录消费状态,成本极低
    > 将所有subject的消息合并在一起

    # 业务使用消息 vs. 数据流处理区别
      > 数据流中消息主题少，每个消息主题的吞吐量极大
      > 业务中消息主题极多，很多主题量级很小

BFF - Backend For Frontend 服务于前端的后端

用户体验适配器

设计原则

  • 计算中所有文件都可以通过添加一个中间层来解决，一个中间层解决不了就添加两个