微服务和软件交付的4个原则


【编者的话】本文介绍了使用微服务架构时需要考虑的问题和遵循的四个原则,对于从传统架构向微服务架构转型起到了很好的指导作用。

【上海站|3天烧脑式微服务架构训练营】培训内容包括:DevOps、微服务、Spring Cloud、Eureka、Ribbon、Feign、Hystrix、Zuul、Spring Cloud Config、Spring Cloud Sleuth等。

微服务是一个杰出的架构,因为这种架构便于对软件系统进行管理。但实际情形是,有很多遗留的应用并没有采用微服务架构,也必须纳入统一的管理范畴。任何一个企业组织,尤其是大型组织机构,都不会使用单一的软件架构。

企业拥抱微服务架构的热情正在持续升温,但就像对待任何技术行业的趋势都应该客观冷静一样,对待微服务架构也是如此。虽然目前微服务架构大行其道,但不应该因为这种趋势而盲目地对应用进行优化和改造。除非是一个创业公司,否则很可能在短时间内就要面临混合架构带来的各种问题。

微服务最大的优势在于, 不需要在同一个周期里面对系统的若干部分进行升级改造。整个系统不需要部署在一起,各个服务可以单独进行部署。如果只需要做很小的改动,不必等到下一个发布周期,因为仅仅修改了整个系统中的一个微服务组件,单独部署这个微服务就可以了。

然而,微服务不是应对所有软件开发和交付问题的灵丹妙药。除非对所有细节问题都了如指掌,否则很容易出错。这四个建议能帮助您在使用微服务的时候充分利用其优势,尽量避免相关的问题。

在开发之前对数据进行拆解

照在微服务的角度,可以将整体应用看作是一组服务,每个服务负责解决问题的不同部分。电子商务应用是一个典型的微服务架构案例。用户需要登录,浏览产品目录,根据推荐信息购物,操作购物车和付款操作等独立的功能。

如果计划将现有的应用向微服务架构迁移,那么必须对系统有着非常深入的了解,并且对各个服务之间如何交互有着清晰的认识。盲目地将整体应用拆分成微服务应用是非常不明智的选择。

对数据模型的任何改动都会对最终的工作量和成本造成直接的影响,这些改动可能是为每个微服务配置单独的数据库,或者是每个微服务一张数据表,也可能是对外键的更新。

总之,我的建议就是:在开发之前先将数据进行拆解。

在原型基础上逐渐迭代扩大

如果希望从零开始写一个应用,那么最好从一个最基本的原型开始迭代。首先,梳理清楚业务域是什么,数据关系是怎样的。处理的数据是关系数据还是事务数据。这些问题的答案对于数据结构至关重要。在将应用重构成微服务架构之前,先搞清楚系统中的依赖关系。

采用微服务架构之后,大部分开发者都希望有一个更好的自动化部署流程,这个流程直接覆盖代码签入到生产环境,与此同时也希望更方便地对整个环境进行监控。有可能当我们发现一个微服务有问题时,真正的问题源头在上游的某个服务。在这种情况下,我们就需要自动回滚有问题的服务,或者在蓝绿发布之间切换。

关注内部服务之间通信细节

服务虚拟化和服务内部通信将带来一些严重的问题。采用微服务架构最重要的一个考量就是有良好的API定义,方便服务发现和彼此之间的交互。开发者使用的是REST,http还是JSON已经变得不再重要,重要的是他们如何使用协议来实现健壮的服务间通信。当服务间的通信由于接口设计不当而产生延迟或者中断时,整个系统就会出现问题。

微服务通常倾向于部署在容器中,因为容器提供了很好的隔离机制,而且很容易地创建和删除,并且只是运行一个进程而已。容器相对于虚拟机来说,占用资源更少,因此资源利用率有着显著提升。

但是如果100个服务运行在100个容器中,将面临运维和管理双重困境。部署将变得更复杂,监控、日志和故障恢复也将越来越重要。

确保开发技能满足架构需要

将应用拆分成微服务形式之后,每个服务都可以使用不同的技术来实现。一个服务使用Java来实现,另一个头像服务是通过静态内容呈现的,再或者用Apache实现其他服务。你可以建立起一个个小型的团队,这些团队彼此依赖,他们负责开发各自的服务,从此再也不用为管理大型团队而担忧。每个团队负责管理自己的产品发布周期,不必被整个产品的发布周期所影响。

大规模地运行容器和微服务所需要的技能要求还是比较高的,目前很多组织尚不具备这种能力。但是每一个团队负责一个单一的应用则难度大大降低。无论从技术还是文化角度来说,在微服务的领域里,我们所熟知的DevOps和持续交付变得尤为重要。

微服务虽然是堪称伟大的架构,但即使新开发的应用全部采用微服务架构,也不得不面临如何处理遗留应用的问题。任何一个企业组织,尤其是大型组织机构,都不会使用单一的软件架构。他们可能有成千上万的各种类型应用程序,有的传统老旧,有的部署在大型机上,有的用的是Java语言,而有的使用COBOL。真正的挑战是如何管理所有的产品交付渠道,怎样将代码变成生产环境中可用的产品,以及如何设计产品交付流水线。

原文链接:4 Rules for Microservices and Software Delivery (翻译:付辉)

0 个评论

要回复文章请先登录注册