ByteCoding

OOP实现方式 在不同的编程语言中，设计者利用各种不同的语言特性来抽象描述对象 最为成功的流派：使用类来描述对象，典型代表为 Java、C++ JavaScript 的实现方式：原型（更冷门！） Like Java JavaScript 诞生之初模仿 Java，在原型运行时引入了 new，this 等语言特性 在 ES6 之前，产生了很多『框架』：试图在原型体系的基础上，把 JavaScript 变得更像是基于类的编程 这些『框架』最终成为了 JavaScript 的古怪方言 任何语言在运行时，类的概念都会被弱化 对象模型基本特征 对象有唯一标识性：完全相同的两个对象，也并非同一个对象 对象有状态：同一对象可能处于不同的状态之下 对象有行为：对象的状态，可能因为它的行为产生变迁 对象的唯一标识，一般是通过内存地址来体现的 123let a = {name: 'A'}let b = {name: 'A'}console.log(a === b) // false 状态和行为，不同语言会使用不同的术语来抽 ...

基本类型 JavaScript 的每一个值都属于某一种数据类型 Undefined Null Boolean String Number Symbol – ES6 Object Undefined + NullUndefined 编程规范：使用 void 0 代替 undefined Undefined 代表未定义，只有一个值undefined undefined为全局变量，但并非关键字 – 语言设计缺陷 任何变量在赋值前的类型为是 Undefined，值为 undefined void 运算可以将任意表达式变成 undefined 值 1console.log(void 0 === undefined) // true Null Null 代表定义了但为空，只有一个值null，null 是关键字 Boolean Boolean 只有两个值，true 和 false，且均为关键字 StringUnicode + UTF Unicode 为字符集，每一个 Unicode 码点表示一个字符 U+??? 基本字符区域（BMP）：U+0000 ~ U+FFFF UTF 为 Unicode ...

函数Main 函数 每个 Go 程序都应该有个main package main package 里的 main 函数是 Go 程序的入口 Init 函数 init 函数会在包初始化时运行，仅运行一次 谨慎使用 样例：A 依次依赖 B 和 C ，但 B 也会依赖 C，初始化顺序：C -> B -> A 返回值 支持多值返回 支持命名返回值：被视为定义在函数顶部的变量 调用者可以忽略部分返回值 回调函数 函数作为参数传入其它函数，并在其它函数内部调用执行 12345678910111213141516func main() { DoOperation(1, increase) DoOperation(1, decrease)}func DoOperation(x int, f func(a, b int)) { f(x, 1)}func increase(a, b int) { fmt.Println(a + b)}func decrease(a, b int) { fmt.Print ...

拷贝数据123456$ docker run -d --rm redis450662153d83e6e1b30af57443ccfe68d798d5c7f4f8e50d2d287fdde2c1645c$ docker psCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES450662153d83 redis "docker-entrypoint.s…" 7 seconds ago Up 6 seconds 6379/tcp cranky_wilbur 拷贝宿主机文件到容器 1234567891011$ md5sum a.txtd41d8cd98f00b204e9800998ecf8427e a.txt$ docker cp a.txt 450:/tmp$ docker exec -it 450 sh# ls /tmpa.txt# md5sum /tmp/a.txtd41d8cd98f00b204e9800998e ...

Registry Registry -> Repository Docker Hub 默认 Registry ImageOfficial Dockerhttps://hub.docker.com/u/library Verified Bitnami / Rancher / Ubuntu Unofficial半官方 开通 Verified publisher，需要付费 民间 个人镜像 Naming user/app:tagtag = version + osslim / fat OS Example Alpine / CentOS alpine3.15 Ubuntu 18.04 bionic Ubuntu 20.04 focal Debian 9 stretch Debian 10 buster Debian 11 bullseye FlowOnline1234567$ docker login -u zhongmingmaoPassword:WARNING! Your passwo ...

Architecture Deployment HA Scene Influence Downgrade Reason 某台 Config Service 下线 无影响 Config Service 无状态 所有 Config Service 下线 Client 无法获取最新配置 Client 重启可获取本地缓存配置 某台 Admin Service 下线 无影响 Admin Service 无状态 所有 Admin Service 下线 用户无法管理配置 某台 Portal 下线 无影响 Portal 无状态 所有 Portal 下线 用户无法管理配置 数据库宕机 用户无法管理配置 Config Service 开启缓存Client 不受影响 Monitoring CAT + Prometheus Reference 微服务架构实战 160 讲

ServerArchitecture 逻辑视图，Software Load Balancer 即 Nginx Module Module Desc Note Config Service 服务对象：Client配置获取接口：推送 + 拉取 Admin Service 服务对象：Portal配置管理接口：修改 + 发布 Client 应用获取配置，实时更新通过 Meta Server 获取 Config Service 服务列表客户端软负载 Portal 配置管理界面通过 Meta Server 获取 Admin Service 服务列表客户端软负载 Eureka 服务注册与发现Config Service 和 Admin Service 向 Eureka 注册并保持心跳与 Config Service 一起部署 Meta Server Eureka Proxy逻辑角色，与 Config Service 一起部署Client 通过域名访问 Meta Server 获取 Config Service 服务列表Portal 通过域名访问 Meta Server 获取 ...

Application 应用的唯一标识 classpath:/META-INF/app.properties -> appid Environment DEV / UAT / PRO /opt/settings/server.properties -> env Cluster - Instance Group - default 一个应用下不同实例的分组（是实例的逻辑分组，并非物理集群），不同的 Cluster，可以有不同的配置 –> 灰度单元组 /opt/settings/server.properties -> idc 默认 Cluster：default Namespace - Item Group - application 一个应用下不同配置的逻辑分组：数据库配置、服务框架配置等也可以关联公共的 Namespace – 可覆盖 默认 Namespace：application Type Note Private 只能被所属应用获取 ...

Feature Flag-Driven Development DevOps 最佳实践 Continuous Delivery Feature flag-driven 比 Agile & test-driven 的反馈周期更短，交付效率更高 Long Lived Branch Merge Hell TBD: Trunk based Development不能随意开分支 Branch by Abstraction 重构 – 抽象接口 + 配置中心 案例：Feature flag-driven Development + Trunk based Development – 依赖于配置中心 Re-planning – 业务功能回退方便，非常灵活 Comparison 优势 劣势 降低发布风险：通过开关，实现新功能和代码发布的分离 代码侵入，有技术债 - 个人不能接受 迭代速度快 需要配置中心支持 投入成本低：无需开发和维护复杂的发布系统 需要 DevOps 文化和流程配合 减少 Merge hell 问题 Reference 微服务架构实战 ...

Option 1 Access Token 为透明令牌，API 网关需要去授权服务器集中校验并兑换成 JWT（自校验），然后再传递到后续的微服务缺点：授权服务器压力比较大 Option 2 全链路无状态，API 网关与授权服务器约定一致的 secret，API 网关可以直接解密 JWT（对称/非对称）缺点：缺少集中校验 Token 的环节，无法通过授权服务器及时吊销，只能等 Token 自然过期 Option 3 生产环境最为常用：原理与 Option 1 类似，只是增加了 Redis 缓存 Reference 微服务架构实战 160 讲