微服务测试的痛点与挑战
这张图可以形象地展示单体服务和微服务的对比,单体应用就像左边巨大的集装箱,软件模块和应用都包括其中;而微服务就像是由一个小集装箱组成,微小的服务组成一个庞大、完整的系统。单体服务是一个大而全的应用体,而微服务由拆分成出来的很多小服务来组成一个庞大而完整的系统。

微服务是一种架构模式,是面向服务型架构 SOA 的一种变体,提倡将单一应用程序逐渐还原划分成小的服务,服务间互相协调、互相配合,为用户提供最终价值。微服务架构风格就是一些小而自治的服务协同工作形成松耦合的系统。另外,我们需要尽量避免一个统一的、集中式的服务管理机制,对具体的一个服务而言,应该根据上下文选择合适的语言工具对其进行构建。
结合下方的这张图,我们可以理解微服务构建的核心其实是中间领域的业务逻辑,围绕着这个领域业务逻辑,会有一些微服务去进行拆分构建。

微服务具有专注、自治、独立进程、独立部署和技术异构的特点,即每个服务只限定于特定的业务而专注做一件事情,每个服务承担的是单一职责,但是它也需要达到一定规模能够完整的处理特定的领域业务。很多人都会被微服务的“微”这个词所误导,认为微服务就是要拆分的越小越好。但是其实为了“微”而将同一领域的业务拆分到不同的服务,只会徒劳增加软件的复杂度和维护困难。
我们可以围绕应用的业务能力进行分组,每个小组的开发组人员开发微服务的技术可以不受限制。每个服务小组可以使用不同的技术架构和存储技术,有针对性地解决一些性能瓶颈问题。每个服务是互相独立部署互不影响的,这样的话我们可以实现独立打包、独立测试和独立附属,减少部署时间,提升研发效率。

最低0.47元/天 解锁文章
535

被折叠的 条评论
为什么被折叠?



