4个实用的微服务测试策略

Jason Limon 微服务架构并不是一种新的架构模式,但它的不断发展为那些寻求企业级私有云解决方案的公司,带来了诸多好处,将大型一体化架构应用拆分为可组合的微服务,赋予企业独立扩展和维护每个组件的能力以及DevOps能力。 当然,微服务架构的分布式和独立性也带了许多挑战,而本文讲谈谈如何克服测试多个可独立部署组件时可能会遇到的挑战。 单元测试(Unit Testing) 单元测试的范围可以是一组服务(社会性单元测试),也可以是单独的一个服务(独立单元测试)。被测试的单元粒度越小,就越容易确定模块的行为、查明相关collaborators以及对象与依赖之间的交互。由于单元的复杂度较低,QA工程师可以通过单元测试策略来评估单元是否与collaborators隔离。社会性单元测试和独立单元测试经常会在同一个代码库中同时进行,以解决不同的测试问题。 测试domain layer的目的是模拟DML语句并证明所有collaborators都以正确的顺序使用真实的domain »

微服务间的通信如何选择

Melvin Koh 如果我们想要构建一个生产就绪的系统,那么必须要权衡所有因素,其中选择微服务间的连接方法更是其中的一个难点。 作者在本文中介绍了一些常见的通信方法,并简要概述了其项目背景以及为何最终选择了RPC。 在决定微服务间连接方法前,我们需要搞清楚两个概念: 架构风格(Architectural Style) 传输协议(Transport Protocol) 架构风格 在使用服务时如何形成有效负载?是有状态还是无状态?我们应该采用REST、SOAP、JSON、XML,还是其他消息格式? 传输协议 我们应该用哪种传输协议?应该采用HTTP、 »

那些微服务和技术堆栈教我们的事

Ashish Sharma在本文中将谈谈企业技术堆栈主流是如何一步步走向微服务架构的,并分享一些经验教训。 过去的技术堆栈如下图所示: 在应用层,我们有一个用Windows form和WPF编写的桌面客户端。应用与服务层对话,而服务层是完全用c#编写的SOA体系结构。这是我们(当时)唯一可以使用的语言。它们是通过WCF相互通信的单片有状态服务。我们使用SQL server作为后端存储。所有这些都在内部部署,这意味着我们的客户购买我们的软件并将其托管在自己的硬件上。 我在金融行业工作(股市准确),是公有云的后期采用者。这个行业不喜欢将数据放在公共云上的想法。我见过的客户会阻止与外部世界进行任何可能的通信,以防止数据泄漏。但随着技术的成熟,种心态已经发生了巨大的变化, »

Rainbond V3.7.1 发布,零配置支持全方位集群资源监控与报警

Rainbond是一款以应用为中心的开源PaaS,由好雨基于Docker、Kubernetes等容器技术自主研发,可作为企业在公有云或私有云环境下的应用交付平台、DevOps平台、自动化运维平台和行业云平台,或作为企业级的混合云多云管理工具、Kubernetes容器管理工具或Service Mesh微服务架构治理工具。 继Rainbond V3.7.0版本大量提高平台稳定性更新后,我们又推出了V3.7.1版本,本次更新进一步完善集群全方位的监控与报警体系。Rainbond集群需要监控的目标分为三类: 节点操作系统和硬件指标 Rainbond每个节点的资源使用情况和健康状况的监控和快速发现故障对于Rainbond运维人员来说是非常必要的。Rainbond Node服务集成了node-exporter,运行于所有节点之上,暴露出经过精简的Prometheus规范的操作系统和硬件的指标。 管理服务监控指标 Rainbond所有服务和第三方服务都提供了Prometheus的exporter »

为什么要使用微服务架构?

微服务架构已经流行了很长时间,但是想要回答为什么要使用微服务架构的问题,首先应该了解一体化架构。 什么是一体化架构? 一体化架构顾名思义,将应用各层打成一个包来部署。为了让代码正常工作,一体化应用的所有组件缺一不可。 以典型的3层传统web应用为例,该应用由用户界面、数据库、服务器端应用组成。这里的服务器端应用被称为monolith(一体化),包含表现、业务层、数据层。所有代码都存在于同一个代码库中。为了让代码工作起来,它被部署成为一个单元。任何一个小的改动变化,都需要重新构建和部署整个应用。 什么是微服务架构? 微服务架构是一种架构风格,整个应用被划分并设计为以业务域为模型的松散耦合的独立服务。微服务中的“ »