代码人生

微服务开发中5个惨痛教训

代码人生 http://www.she9.com 2018-07-24 20:25 出处:网络 编辑:@技术狂热粉
基于微服务的开发正在改变我们整个行业,超过70%的人正在尝试开发基于微服务的软件。微服务简化了业务、流程、技术和人员的集成,将大爆炸的整体问题分解为一个可以独立处理的小集合。然而,它也带来了管理这些小集合

基于微服务的开发正在改变我们整个行业,超过70%的人正在尝试开发基于微服务的软件。微服务简化了业务、流程、技术和人员的集成,将大爆炸的整体问题分解为一个可以独立处理的小集合。然而,它也带来了管理这些小集合之间关系的问题。我们需要不同的过程、工具、培训、方法和团队来简化微服务开发。

我们的Microservices-Based项目

我们一直在开发一个关于微服务体系结构的高度复杂的项目,我们每天导入大量的观测数据,并建立统计模型来预测未来的需求。最终用户可以交互影响统计模型和预测方法。用户可以通过模拟影响来分析需求。有大约50个有界的上下文,100多个独立的部署单元在REST和消息传递上进行通信。运行整个系统需要200多个流程实例。我们从零开始开始这个项目,在微服务方面几乎没有任何实践经验,我们在项目规划、培训、测试、质量管理、部署和操作方面面临许多问题。

我将分享帮助我们克服这些问题的五大经验。

1、调整开发方法和项目计划

微服务开发中5个惨痛教训


敏捷开发方法被认为是微服务开发的最佳方法,但前提是一致性良好。单体开发有一个可交付的和一个流程管道,但是微服务不同,我们有多个可交付的,所以除非我们对每个可交付的流程管道进行对齐,否则我们将无法实现预期的微服务开发的有效性。

我们也面临着项目规划的问题,因为我们不能很好地规划产品和用户故事,这可以产生独立的产品,我们可以应用流程管道。我们无法向最终用户演示业务价值,因为我们的产品工作流只有在此之后才准备好。我们曾经有非常大的用户故事,它有时超越了多个sprint,并影响微服务的数量。

考虑项目规划的以下方面:

1、为需求定义、架构、开发、DevOps和基础设施运行并行的sprint管道。为常见的问题和集成点组织一个Scrum。

2、为架构和DevOps保留少量的初始冲刺,并且只有在架构的第一个稳定版本和DevOps建立之后才开始开发冲刺。

3、架构PoCs和决策任务应该在实际开发脚本之前计划好几个sprint。

3、为每个sprint定义度量,以定量地度量项目质量。

4、清楚地指出在待办事项列表中的架构变更,并将它们优先排序。根据项目的当前规模和对微服务的影响,考虑他们的适应工作。

5、制定基础设施资源(专家、软件、硬件或工具)计划。

6、配置管理。

7、在项目导入中包括敏捷培训。

8、在Ready (DoR)的定义和Done的定义中包含多个sprint工件依赖项。

9、培训产品负责人和项目计划人员计划需求定义、体系结构等方面的scrum,以便他们实现DoR。

10、有更小的用户故事,确保在sprint中选择的故事是真正的单元大小,这将影响很少的部署单元。

11、如果在一个特定的sprint中添加了一个新的微服务,那么考虑一下CI/CD、基础设施、DevOps的工作。

2、定义基础设施管理策略

在一个单体的应用中,基础设施管理在项目开始时并不是那么重要,所以与相关的任务可能会被延迟,直到稳定的交付开始,但是,在微服务开发中,部署单元很小,部署单元的数量也很高,因此需要一个强大的基础设施管理策略。

在项目中,我们需要花费大量精力来简化项目的内部组件,这对实现的功能范围有很大的副作用。

这里的基础设施包括横切组件、支持工具和运行系统所需的硬件/软件。服务注册、发现、API管理、配置、跟踪、日志管理、监视和服务健康检查等可能需要单独的工具。

在基础设施管理中至少考虑以下几点:

1、能力计划——从项目开始就进行能力计划,然后定期检查/调整。

2、提前获得所需的基础设施(软件/硬件/工具),并在团队采用它们之前进行测试。

3、定义一个硬件/软件/服务入职计划,该计划涵盖不同物理环境中的工具的细节,如开发测试、QA测试、性能测试、登台、UAT、Prod等。

3、考虑多个扩展的开发测试/集成环境,因为多个开发人员需要测试他们的工件,并且他们的开发机器可能不能保存所需的服务。

4、在基础设施管理专家的基础上加速项目的设置。

5、在项目的早期阶段定义部署策略并计划其实现。不要采用中间部署方法。如果您想要使用Docker和基于kubernet的部署,那么从项目开始就执行它——不要等待并推迟它的实现。

6、定义访问管理和资源配置策略。

7、对基础设施进行自动、主动的监控。

8、跟踪与项目范围并行的基础设施开发。

3、定义基于微服务的体系结构及其演化

微服务可以独立开发和部署,但最终,很难在整个服务开发过程中维护标准和实践。一个基本的体系结构需要遵循微服务,然后让体系结构演进,这在这里可能会有所帮助。

我们已经定义了一个非常基本的体系结构,其中包含了日志记录、引导和一些常见的方面的核心平台。但是,我们考虑了演进过程中的许多内容,如消息传递、数据库、缓存、文件夹结构、压缩/解压缩等,它导致平台与微服务的功能范围并行地进行了大量更改。在跳转到功能范围冲刺之前,我们没有给核心平台足够的时间。

在基本架构中考虑以下内容,并在功能范围实现之前很好地实现它。不要过于依赖“从制度中学习,然后随机应变”这句话。

1、提前定义体系架构,保持领先的情况下,尽快和获得知识。

2、定义一个涵盖横切关注点和抽象的核心平台。核心平台可以包括日志记录、跟踪、引导、压缩/解压缩、加密/解密、公共方面、拦截器、请求过滤器、配置、异常等。平台还可以包含消息传递、缓存和数据库的抽象。

3、微服务结构——定义具有命名转换的文件夹和代码结构。

4、为CI/CD构建一个机制——定义一个CD策略,甚至是本地QA环境,以避免在UAT/pre-UAT环境中直接遇到问题。

5、定义一个架构变更策略——如何交付架构变更以及如何调整它们。

6、源代码、API、构建、配置和文档的版本策略。

7、继续验证NFRs的设计。

8、定义测试架构以覆盖测试策略。

用明确定义的有界上下文和数据隔离来记录模块架构。

4、团队管理

微服务世界需要一种与单体世界不同的思维方式。每个微服务可以被认为是独立的,因此不同微服务的开发人员也是独立的。这会带来了差异性的挑战:我们希望我们的开发人员来管理代码一致性单元,遵循同样的编码标准,并在上面建立核心平台。同时,我们希望他们不要信任其他microservices的代码,因为它可能是由一些其他公司的开发人员开发出来的。

在你的团队管理中考虑以下事项:

1、向负责维护配置和依赖信息的少数团队成员定义“配置管理”的职责。

2、定义由开发人员/架构师组成的“合同管理”团队,他们负责定义微服务之间的交互。

3、基于有界上下文分配模块所有者和团队。他们负责与所分配的模块相关的所有事情,并向“配置管理”团队通报公众关注的事项。

4、开发人员应该只通过合同进行交流,否则他们将是一个完全独立的团队。如果合同中需要任何变更,则应通过“合同管理”进行。

5、从开发团队定义DevOps团队。一个人可以轮班,让每个人都了解操作系统。

6、鼓励团队中掌握多种技能。

7、自我激励团队。

9、持续的培训计划。

5、持续分享知识

微服务每天都在发展,会不断引入许多新的工具和概念。团队知识构成需要及时更新。由于微服务体系结构相对独立,如果需要,您可以更改微服务的技术栈。由于团队是独立的,我们需要在团队中不断地分享知识。

我们面临的问题是,相同/类似的问题正在被不同的团队复制,他们试图以不同的方式来解决它们。比如:团队在理解有界上下文、数据隔离等方面面临的问题。

考虑以下内容:

1、对团队进行领域驱动设计、有界上下文、数据隔离、集成模式、事件设计、持续部署等方面的培训。

2、创建一个学习数据库,每个团队可以在sprint回顾中提交条目。

3、训练团队遵循单元测试、模拟和集成测试。大多数时候,“单元”的定义被开发人员误解。“集成测试”是最低优先级。它必须遵循;如果处理得当,它应该是最简单的东西。

4、分享性能方面技术知识——例如:

不要过度循环

有效地利用缓存

使用RabbitMQ消息传递作为Flow,而不是作为数据存储

并发消费者和发布者

数据库分区和集群

不重复

结论

微服务正以很快的速度普及,随着时间的推移,会变得越来越成熟。我已经分享了我们在基于微服务的项目中所经历的一些痛苦的教训。我希望这将有助于您的项目避免错误。


请关注公众号:程序你好
0

精彩评论

暂无评论...
验证码 换一张
取 消