Go Engineering - Foundation - RD
功能需求
为 iamctl 新增 helloworld 命令,该命令向终端打印 hello world
开发阶段代码开发
选择 Git Flow:适用于大型非开源项目
创建分支
基于 develop 分支,新建一个功能分支 feature/helloworld
1$ git checkout -b feature/helloworld develop
branch 名要符合 Git Flow 的分支命名规范,会通过 pre-commit 的 githook 来确保分支名符合规范
123$ md5 ./githooks/pre-commit ./.git/hooks/pre-commitMD5 (./githooks/pre-commit) = 3324d20a738461f3b6347f9ce7dae6b6MD5 (./.git/hooks/pre-commit) = 3324d20a738461f3b6347f9ce7dae6b6
./.git/hooks/pre-commit123456789101112131415161718#!/usr/bin/env bashLC_ALL= ...
Go Engineering - Foundation - Makefile
使用
先编写 Makefile 文件,指定整个项目的编译规则,然后通过 Linux make 命令来解析该 Makefile 文件,实现自动化
默认情况下,make 命令会在当前目录下,按照 GNUmakefile、makefile、Makefile(推荐)的顺序查找
make -f golang.mk 或者 make --file golang.mk
规则
规则一般由目标、依赖和命令组成,用来指定源文件编译的先后顺序
Makefile 规则可以自动判断是否需要重新编译某个目标,从而确保目标仅在需要时编译
规则语法
主要包括:target、prerequisites 和 command
1234target ...: prerequisites ... command ... ...
target
可以是一个 object file,也可以是一个执行文件,还可以是一个标签
可以使用通配符,当有多个目标时,使用空格分隔
prerequisites:代表生成该 target 所需要的依赖项,当有多个依赖项时,使用空格分隔
command:代表该 target 要执行 ...
Go Engineering - Foundation - API - RPC
RPC
Client 通过本地调用,调用 Client Stub
Client Stub 将参数打包(Marshalling)成一个消息,然后发送这个消息
Client 所在的 OS 将消息发送给 Server
Server 接收到消息后,将消息传递给 Server Stub(或者 Server Skeleton)
Server Stub 将消息解包(Unmarshalling)后得到消息
Server Stub 调用服务端的子程序,处理完成后,将最终结果按照相反的步骤返回给 Client
gRPC概述
gRPC:google Remote Procedure Call
gRPC 是由 Google 开发的高性能、开源、跨语言的通用 RPC 框架,基于 HTTP 2.0,默认使用 Protocol Buffers 序列化
gRPC 的特点
支持多语言
基于 IDL(Interface Definition Language)文件定义服务
通过 proto3 生成指定语言的数据结构、服务端接口和客户端 Stub
通信协议基于标准的 HTTP/2,支持特性:双向流、消息头压缩、单 TCP ...
Go Engineering - Foundation - API - RESTful
概述
REST:Representational state transfer
REST 只是一种软件架构风格,是一组架构约束条件和原则,而不是技术框架
REST 有一系列规范,满足这些规范的 API 均可称为 RESTful API
REST 规范把所有内容都视为资源,对资源的操作对应 HTTP 协议提供的 GET、POST、PUT 和 DELETE 方法
由于 REST 与 HTTP 协议相辅相成,因此 HTTP 协议已经成为 RESTful API 的事实标准
特点
以资源为中心,一切都可以抽象成资源,所有行为都是对资源的 CRUD
资源对应着面向对象范式里面的对象
资源使用 URI 标识,每个资源实例都有一个唯一的 URI 标识
资源是有状态的,使用 JSON/XML 等在 HTTP Body 里表征资源的状态
客户端通过 HTTP Method 对资源进行操作,实现 REST
无状态:每个 RESTful API 请求都包含了所有足够完成本次操作的信息,服务器无需保持 Session
无状态对于服务端的弹性扩容是很重要的
设计原则
RESTful API 的核心是规范
...
Go Engineering - Specification - Design Pattern
GoF
创建型模式
提供一种在创建对象的同时隐藏创建逻辑的方式,而不是直接使用 new 运算符直接实例化对象
单例模式
分为饿汉方式(包被加载时创建)和懒汉方式(第一次使用时创建)
饿汉方式1234567891011package hungertype singleton struct {}// 实例是在包被导入时被初始化的var ins *singleton = &singleton{}func GetIns() *singleton { return ins}
懒汉方式
非并发安全,需要加锁
1234567891011121314151617181920package singletonimport "sync"type singleton struct {}var ins *singletonvar lock sync.Mutexfunc GetIns() *singleton { if ins == nil { lock.Lock() ...
Go Engineering - Specification - Design Method
Go 项目
Go 项目是一个偏工程化的概念,包含 Go 应用
Go 应用
代码结构按层拆分
最大的问题:相同功能可能在不同层被使用,而这些功能又分散在不同的层中,容易造成循环引用
12345678910├── controllers│ ├── billing│ ├── order│ └── user├── models│ ├── billing.go│ ├── order.go│ └── user.go└── views └── layouts
按功能拆分
Go 项目最常用的拆分方法
不同模块,功能单一,可以实现高内聚低耦合的设计哲学
所有功能只实现一遍,引用逻辑清晰,大大减少循环引用的概率
12345pkg├── billing├── order│ └── order.go└── user
代码规范编码规范
Uber Go 语言编码规范
静态代码检查工具:golangci-lint
最佳实践
Effective Go
Go Code Review Comments
Style guideline for Go packages
代码质量编写可测试 ...
Cloud Native - Security & Compliance - OPA - Philosophy
Overview
A policy is a set of rules that governs the behavior of a software service.
Authorization is a special kind of policy.
difference
Authentication: how people or machines prove they are who they say they are.
Authorization: which people or machines can run which actions on which resources.
Authorization and more generally policy often utilize the results of authentication (the username, user attributes, groups, claims), but makes decisions based on far more information than just who the user is.
...
Cloud Native - Security & Compliance - OPA - Introduction
Overview
The Open Policy Agent is an general-purpose policy engine that unifies policy enforcement across the stack.
OPA provides a high-level declarative language
that lets you specify policy as code and simple APIs to offload policy decision-making from your software.
OPA decouples policy decision-making from policy enforcement.
When your software needs to make policy decisions it queries OPA and supplies structured data (e.g., JSON) as input.
OPA accepts arbitrary structured data as input.
OPA genera ...
Cloud Native - Security & Compliance - OPA - Glance
Overview
Policy-based control for cloud native environments
Flexible, fine-grained control for administrators across the stack
Use OPA for a unified toolset and framework for policy across the cloud native stack.
Decouple policy from the service’s code, so you can release, analyze, and review policies without sacrificing availability or performance.
Declarative Policy
Declarative
Express policy in a high-level, declarative language that promotes safe, performant, fine-grained controls.
DSL : Use a langua ...
Go Engineering - Specification - Life Cycle
生命周期管理
研发模式瀑布模式
按照预先规划好的研发阶段来推进研发进度,串行执行(在每个阶段完美完成后,才会进入到下一阶段)
迭代模式
研发任务被切成一系列轮次,每一个轮次是一个迭代,每一次迭代都是从设计到实现的完整过程
不要求每个阶段的任务都做到最完美,先把主要功能搭建起来,然后再通过客户的反馈信息不断完善
缺点:比较专注于开发过程,很少从项目管理的视角去加速和优化项目开发过程
敏捷模式
将一个大的需求分成多个、可分阶段完成的小迭代,在开发过程中,软件一直处于可用状态!
敏捷模式需要高频地开发、构建、测试、发布和部署,进而催生了 CICD 技术
CICD
CICD 通过自动化的手段,快速执行代码检查、测试、构建、部署等任务,解决敏捷模式带来的弊端
CI:Continuous Integration
频繁地将开发者的代码合并到主干上
流程
开发人员完成代码开发,push 到 git 仓库
CI 工具对代码进行扫描、单元测试和构建,并将结果反馈给开发者
CI 通过后会将代码合并到主干
CI 可以让问题在开发阶段暴露,CI 执行很频繁,需要自动化工具支撑
CD:Continuous Del ...