ByteCoding

使用 先编写 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 要执行 ...

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 ...

概述 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 的核心是规范 ...

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 项目 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 代码质量编写可测试 ...

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. ...

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 ...

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 ...

生命周期管理 研发模式瀑布模式 按照预先规划好的研发阶段来推进研发进度，串行执行（在每个阶段完美完成后，才会进入到下一阶段） 迭代模式 研发任务被切成一系列轮次，每一个轮次是一个迭代，每一次迭代都是从设计到实现的完整过程 不要求每个阶段的任务都做到最完美，先把主要功能搭建起来，然后再通过客户的反馈信息不断完善 缺点：比较专注于开发过程，很少从项目管理的视角去加速和优化项目开发过程 敏捷模式 将一个大的需求分成多个、可分阶段完成的小迭代，在开发过程中，软件一直处于可用状态！ 敏捷模式需要高频地开发、构建、测试、发布和部署，进而催生了 CICD 技术 CICD CICD 通过自动化的手段，快速执行代码检查、测试、构建、部署等任务，解决敏捷模式带来的弊端 CI：Continuous Integration 频繁地将开发者的代码合并到主干上 流程 开发人员完成代码开发，push 到 git 仓库 CI 工具对代码进行扫描、单元测试和构建，并将结果反馈给开发者 CI 通过后会将代码合并到主干 CI 可以让问题在开发阶段暴露，CI 执行很频繁，需要自动化工具支撑 CD：Continuous Del ...

集中式 在本地仓库的 master 分支开发，将修改后的代码 commit 到远程仓库，如有冲突先本地解决再提交 适合场景：团队人员少、开发不频繁、不需要同时维护多个版本的小项目 功能分支 12345678910# git checkout -b feature/rate-limiting# git add limit.go# git commit -m "add rate limiting"# git push origin feature/rate-limiting# Github: Compare & pull request -> Create pull request# Github: Code Review -> Merge pull request Merge PR Create a merge commit – 推荐 底层操作：git merge --no-ff With --no-ff, create a merge commit in all cases, even when the merge could instead be re ...