Apollo - HA + Monitoring
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 讲
Apollo - Architecture
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 ...
Apollo - Core Concept
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 只能被所属应...
DevOps - Feature Flag-Driven Development
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 微服务架...
Microservices - Security Architecture
Option 1 Access Token 为透明令牌,API 网关需要去授权服务器集中校验并兑换成 JWT(自校验),然后再传递到后续的微服务缺点:授权服务器压力比较大 Option 2 全链路无状态,API 网关与授权服务器约定一致的 secret,API 网关可以直接解密 JWT(对称/非对称)缺点:缺少集中校验 Token 的环节,无法通过授权服务器及时吊销,只能等 Token 自然过期 Option 3 生产环境最为常用:原理与 Option 1 类似,只是增加了 Redis 缓存 Reference 微服务架构实战 160 讲
Oauth2 - Github
Module 模块 描述 spring-security-oauth2-core OAuth2 授权框架 + OIDC 核心数据结构及接口 spring-security-oauth2-jose 支持 JOSE 协议组JWT: JSON Web TokenJWS: JSON Web SignatureJWE: JSON Web EncryptionJWK: JSON Web Key spring-security-oauth2-client 支持 OAuth2 和 OIDC 的客户端 Register application callback: /login/oauth2/code/github Config callback template: {baseUrl}/login/oauth2/code/{registrationId} 12345678910server: port: 9000spring: security: oauth2: client: ...
Kubernetes - Dockerfile
Image 镜像由多层 Layer 组成,Layer 是一组只读不可修改的文件,Layer 可以在镜像间共享Image = Layer + Union FS 1234567891011121314$ docker inspect nginx:alpine... "RootFS": { "Type": "layers", "Layers": [ "sha256:e5e13b0c77cbb769548077189c3da2f0a764ceca06af49d8d558e759f5c232bd", "sha256:07099189e7ec257e501d9625507b55e0ea32c330e38c90d8533b3fa2a7a97069", "sha256:fcf860bf48b4e20f24f44ba02...
Kubernetes - Containerization
镜像 只读:依赖的文件系统、依赖库、环境变量、启动参数等 核心解决的问题:应用分发 应用容器化 应用不再直接与 OS 打交道,而是封装成镜像,再交给容器环境去运行 常用命令镜像 命令 作用 docker pull 从远端仓库拉取镜像 docker images 列出当前本地已有的镜像 docker rmi 删除不再使用的镜像 容器12$ docker run -h srv --rm alpine hostnamesrv 1234567891011121314151617181920$ docker run -d nginx:alpine6376e2649ef2d4a6073b977fcc4408f7a3f21b6f32775b42be85711b989dd6ce$ docker run -d --name redis_srv redis2a79d491ecb3108b07df7d369dfe8abc6ac314efc2054951ef7b77e0deba0584$ docker run -it --name ubuntu ubuntu sh# cat /etc/o...
Oauth2 - JWT
Token Type JWT 资源服务器自解释和自校验,无需再跟授权服务器交互 结构 验签 issue + audience issue:令牌签发人audience:目标接收人 CodeAuthorization ServerMaven12345678910111213141516171819<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-security</artifactId> </dependency> ...
Kubernetes - Docker Nature
本质 容器,是一个特殊的隔离环境,能够让进程只看到这个环境内的有限信息,不能对外界环境施加影响隔离的原因:系统安全隔离的实现:namespace + cgroup + chroot(rootfs) Container vs VM 容器并不是直接运行在 Docker 上,Docker 只是辅助建立隔离环境,让容器基于 Linux 运行 VM 虚拟化出来的是硬件,需要在上面再安装一个 Guest OS 才能运行应用程序,会消耗大量的系统资源 容器则直接利用了下层的计算机硬件和操作系统,非常轻量级,但多个容器共用 OS Kernel,隔离程度不如 VM 实现方式 优势 劣势 VM 虚拟化硬件 隔离程度非常高 资源消耗大,启动慢 Container 直接利用下层的硬件和操作系统 资源利用率高运行速度快 隔离程度较低










