2019年云原生时代的应用开发-微服务、service mesh与serverless.pdf

1、云原生时代的应用开发：微服务、service mesh与serverless应用云原生微服务容器CI/CDDevOps服务网格无服务器本交流包含以下内容 云原生应用设计的一些指导思想 衡量微服务架构的一种角度 微服务、服务网格、无服务器的各种玩法 业务微服务化的一些示例云原生00什么是云原生？容器 微服务 服务网格 不可变基础设施 声明式API 自动化 弹性 持续交付微服务概述01微服务大量功能在单个服务里整体部署，整体扩展单个服务包含独立的一组功能分别部署，分别扩展切分配合+切分要切分的不只是业务逻辑 数据 配置 工具 运行环境 切分指导方针 Domain Driven Design（领域驱

2、动设计）Twelve-Factor App（十二要素）Beyond the Twelve-Factor App这些方针主要针对业务应用，基础组件服务有部分不太适用应用设计时请记住 应用中需要的功能不一定需要自己实现 应用可能被不同人运行在很多个环境 应用运行中可能随时会发生故障 应用未来会需要被不同人进行很多次升级一些可能的做法 为了让我的程序可以运行在各套环境，我的代码资源中为各套环境提供了相应配置文件/src/main/resources-application-dev.yaml-application-test.yaml-application-pre.yaml-application-

3、prod.yaml 为了减少网络调用提高性能，我让依赖的X服务封装成SDK，我直接本地调用 为了提高性能，我从数据库把数据直接加载到本地内存缓存起来基准代码 一份基准代码（Codebase），多份部署（deploy）不同应用的代码在一个代码库 线上常态化运行一个代码库多个分支 线上直接修改代码 不同应用的代码用不同代码库 相同逻辑抽象为类库或者单独服务 在代码库修改代码并重新测试上线建议的方式不好的方式依赖 显式声明依赖关系（dependency）依赖项不明确 确切声明依赖项建议的方式不好的方式配置 在环境中存储配置 代码中写死配置 在代码库中包含配置文件 环境变量*全局配置服务*每个环境分别

4、管理的配置文件*建议的方式不好的方式后端服务 把后端服务(backing services)当作附加资源 要求后端服务必须以某种方式部署在某个网络位置 应用与后端服务松耦合，后端服务只是一个可替换的网络地址 更多使用独立的后端服务而不是全部自己实现建议的方式不好的方式构建，发布，运行 严格分离构建和运行 线上直接修改代码 上线过程遇到问题立即修改代码直接上线 在代码库修改代码并重新测试上线 上线过程遇到问题先回滚建议的方式不好的方式进程 以一个或多个无状态进程运行应用 使用本地磁盘存储数据 应用内存保存不可重新载入的关键数据 粘滞会话 使用单独的存储服务 应用完全无状态 可以用本地缓存，但必须

5、是可以从存储服务重建的 分布式缓存Session数据建议的方式不好的方式端口绑定 通过端口绑定(Port binding)来提供服务 监听端口代码中写死 所有服务都监听80 主要靠ip来区分服务 通过配置指定监听端口，并绑定到对外端口上建议的方式不好的方式并发 通过进程模型进行扩展 使用更大的机器以便启动更多的线程 使用本地锁实现同步 扩展更多的进程实例 减少需要锁定的资源，若需要使用分布式锁 投入更多精力优化应用的整体性能，而不是单个进程的性能建议的方式不好的方式易处理 快速启动和优雅终止可最大化健壮性 启动时加载大量数据 请求处理中包含大量逻辑 请求处理未完成前不可终止 应用被设计成可以随

6、时终止随时重新启动 优雅终止：先停止接受新请求，同时将正在处理的请求精力执行完成建议的方式不好的方式开发环境与线上环境等价 尽可能的保持开发，预发布，线上环境相同 开发环境使用本地缓存和SqlLite，线上用分布式缓存和数据库 开发或预发环境关闭某些配置 每个月打包一大堆功能整体上线 开发和线上依赖的服务要完全一致 每个小功能独立上线建议的方式不好的方式日志 把日志当做事件流 应用本地存储日志 应用统一收集和展现建议的方式不好的方式管理进程 后台管理任务当作一次性进程运行 管理服务可以随便搞 同样遵循上述要素建议的方式不好的方式API优先 合理、高兼容性的API作为服务间交互的契约 集成能力提