数组与矩阵 数组中重复的数字 1 2 3 4 5 6 7 8 class Solution: def findRepeatNumber(self, nums: List[int]) -> int: dic ={} for num in nums: if num not in dic: dic[num] = True else: return num 二维数组中的查找 1 2 3 4 5 6 7 8 9 10 11 class Solution: def findNumberIn2DArray(self, matrix: List[List[int]], target: int) -> bool: if not matrix or not matrix[0]:return False col = len(matrix)-1 row = len(matrix[0])-1 _i,_j = col, 0 while _i>=0 and _j<=row: if matrix[_i][_j]>target:_i-=1 elif matrix[_i][_j]<target:_j+=1 else: return True return False 替换空格 1 2 3 4 5 6 7 8 9 class Solution: def replaceSpace(self, s: str) -> str: ans =[] for c in s: if c == " ": ans.

STAR 用于 工作总结、面试 S 背景 基于什么样的情况 T 任务 设定了什么样的目标 A 行动 用了什么样的方案 R 结果 得到了什么样的结果 SCQA 用于 开会、营销文案、演讲 S 背景 基于什么样的情况 C 冲突 遇到了什么问题 Q 问题 需要如何解决 A 回答 提出了什么样的方案 5W2H 用于 计划、推动 What 目的是什么 why 为什么 who 谁去做 when 什么时候 where 在哪 how 方案是什么 how much 成本是多少 which one is better 用于说服、争取 FOSSA 用于说服别人、处理投诉、跨部门沟通 F 认同感受 O 共同目标 S 现状 S 解决方案 A 达成共识 Yes+And 法则 用于拒绝别人 正面的肯定 肯定的原因 自己的难处

中文简历 我的简历 英文简历 My Resume

摘要 什么是云原生？ 什么是12要素 云原生应该关注什么？ 微服务架构 敏捷基础设施及公共基础服务 分布式架构设计 云原生程度的评判标准是什么？ 云服务现在如何，未来怎么走？ 什么是云原生 云原生的概念最早开始于 2010 年，在当时 Paul Fremantle 的一篇博客中被提及，他一直想用一个词表达一种架构，这种架构能描述应用程序和中间件在云环境中的良好运行状态。因此他抽象出了 Cloud Native 必须包含的属性，只有满足了这些属性才能保证良好的运行状态。当时提出云原生是为了能构建一种符合云计算特性的标准来指导云计算应用的编写。 后来到 2013 年 Matt Stine 在推特上迅速推广云原生概念，并在 2015 年《迁移到云原生架构》一书中定义了符合云原生架构的特征：12 因素、微服务、自服务、基于 API 协作、扛脆弱性。而由于这本书的推广畅销，这也成了很多人对云原生的早期印象，同时云原生也被 12 要素变成了一个抽象的概念。Matt Stine 认为在单体架构向 Cloud Native 迁移的过程中，需要文化、组织、技术共同变革。 12要素 2012 年，Heroku 创始人 Adam Wiggins 发布十二要素应用宣言。它为构建一个优雅的互联网应用，定义了需要遵循的一些基本原则和方法论，也广泛影响了众多的微服务应用架构。十二要素重点关注：应用程序的健康成长，开发者之间的有效的协作，以及避免软件架构腐化的影响。 基准代码：一份基准代码，多份部署，使用 GIT 或者 SVN 管理代码，并且有明确的版本信息。 依赖：显示声明依赖。 配置：环境中存储配置。 后端服务：把后端服务当作附加资源。后端服务是指程序运行所需要的通过网络调用的各种服务，如数据库（MySQL、CouchDB）、消息/队列系统（RabbitMQ、Beanstalkd）、SMTP 邮件发送服务（Postfix），以及缓存系统（Memcached）。 构建、发布、运行：严格分离构建和运行。 进程：以一个或多个无状态进程运行应用，如果存在状态，应该将状态外置到后端服务中，例如数据库、缓存等。 端口绑定：通过端口绑定提供服务，应用通过端口绑定来提供服务，并监听发送至该端口的请求。 并发：通过进程模型进行扩展，扩展方式有进程和线程两种。进程的方式使扩展性更好，架构更简单，隔离性更好。线程扩展使编程更复杂，但是更节省资源。 易处理：快速启动和优雅终止可最大化健壮性，只有满足快速启动和优雅终止，才能使服务更健壮。 开发环境与线上环境等价：尽可能保持开发、预发布、线上环境相同。 日志：把日志当作事件流，微服务架构中服务数量的爆发需要具备调用链分析能力，快速定位故障。 管理进程：把后台管理任务当作一次性进程运行，一些工具类在生产环境上的操作可能是一次性的，因此最好把它们放在生产环境中执行，而不是本地。 12 要素应用为我们提供了很好的架构指导，帮助我们：

测试方法 软件测试阶段 单元测试 重点：模块接口，局部数据结构，重要的执行通路，出错处理通路，边界条件 集成测试 非渐增式，渐增式 系统测试 确认测试（需求说明书检查，软件配置复查），验收测试（alpha，beta） 白盒测试和黑盒测试 白盒测试 语句覆盖，判定覆盖，条件覆盖，判定/条件覆盖，条件组合覆盖，路径覆盖 黑盒测试 等价类划分，边值分析，错误推测，因果图 缺陷的分类和级别 分类：输入/输出错误，逻辑错误，计算错误，接口错误，数据错误 级别：轻微，中等，使人不悦，影响使用，严重，非常严重，极为严重，无法容忍，灾难性，传染性 调试 排错策略：原始类，回溯类，排除类 评审方法 软件需求评审，概要设计评审，详细设计评审，软件验证和确认评审，功能检查，物理检查，综合检查，管理评审 注意：不应以测试代替评审，评审人员应关注产品而不应评论开发人员，评审人员应关注实质性问题，评审会议不应变为问题解决方案讨论会，评审应被安排进入项目计划，评审参与者应了解整个评审过程，评审人员事先应对评审材料充分了解，应重视评审的组织工作 验证与确认 验证：合同验证，过程验证，需求验证，设计验证，编码验证，集成验证，文档验证 确认 测试自动化 测试用例生成，测试执行控制，测试结果对比，测试结果分析，总测试状况的统计与报表产生 面向对象测试 OOA测试，OOD测试，OOP测试，单元测试，集成测试，系统测试

独享数据库（Database per Microservice） 当一家公司将大型单体系统替换成一组微服务，首先要面临的最重要决策是关于数据库。单体架构会使用大型中央数据库。即使转移到微服务架构许多架构师仍倾向于保持数据库不变。虽然有一些短期收益，但它却是反模式的，特别是在大规模系统中，微服务将在数据库层严重耦合，整个迁移到微服务的目标都将面临失败（例如，团队授权、独立开发等问题）。 更好的方法是为每个微服务提供自己的数据存储，这样服务之间在数据库层就不存在强耦合。这里我使用数据库这一术语来表示逻辑上的数据隔离，也就是说微服务可以共享物理数据库，但应该使用分开的数据结构、集合或者表，这还将有助于确保微服务是按照领域驱动设计的方法正确拆分的。 优点 数据由服务完全所有。 服务的开发团队之间耦合度降低。 缺点 服务间的数据共享变得更有挑战性。 在应用范围的保证 ACID 事务变得困难许多。 细心设计如何拆分单体数据库是一项极具挑战的任务。 何时使用独享数据库 在大型企业应用程序中。 当团队需要完全把控微服务以实现开发规模扩展和速度提升。 何时不宜使用独享数据库 在小规模应用中。 如果是单个团队开发所有微服务。 可用技术示例 所有 SQL、 NoSQL 数据库都提供数据的逻辑分离（例如，单独的表、集合、结构、数据库）。 延伸阅读 微服务模式：独享数据库 https://microservices.io/patterns/data/database-per-service.html 分布式数据存储 https://docs.microsoft.com/en-us/dotnet/architecture/cloud-native/distributed-data 事件源（Event Sourcing） 在微服务架构中，特别使用独享数据库时，微服务之间需要进行数据交换。对于弹性高可伸缩的和可容错的系统，它们应该通过交换事件进行异步通信。在这种情况，您可能希望进行类似更新数据库并发送消息这样的原子操作，如果在大数据量的分布式场景使用关系数据库，您将无法使用两阶段锁协议（2PL），因为它无法伸缩。而 NoSQL 数据库因为大多不支持两阶段锁协议甚至无法实现分布式事务。 在这些场景，可以基于事件的架构使用事件源模式。在传统数据库中，直接存储的是业务实体的当前“状态”，而在事件源中任何“状态”更新事件或其他重要事件都会被存储起来，而不是直接存储实体本身。这意味着业务实体的所有更改将被保存为一系列不可变的事件。因为数据是作为一系列事件存储的，而非直接更新存储，所以各项服务可以通过重放事件存储中的事件来计算出所需的数据状态。 优点 为高可伸缩系统提供原子性操作。 自动记录实体变更历史，包括时序回溯功能。 松耦合和事件驱动的微服务。