王作敬
作者王作敬2018-11-22 09:39
管理信息系统总监, 银河证券

微服务生命周期

字数 4585阅读 3861评论 0赞 6

作者:汪照辉 王作敬


前面我们讨论过微服务的五个实施阶段 :可行性评估级、采用级、应用级、企业级、生态级,不过这对于微服务的具体怎么实施有点断代,很多人感觉无从下手。最近我们也一直在考虑新业务应用系统重构并用微服务架构设计构建,以及我们目前已实施的微服务的改造和改进问题。正好有合作伙伴请求在微服务和容器云方面做个技术交流,所以就把想法整理了一下。
微服务实施需要明确每一步怎么做,可能存在的问题和解决思路、方法。如果能有相应的经验和理论指导,将会大大有助于我们设计和构建微服务体系。但由于目前大部分人员都是关注微服务开发框架或工具,甚少讨论微服务架构方法论。因此,进行微服务规划,在一个相对较高的层次来探讨、研究微服务的设计和实现显得尤为重要。就像我们需要高举社会主义旗帜,在毛泽东思想、邓小平理论指导下才能昂首阔步前进。理论方法论就象灯塔、导航,为我们指明了方向,虽然也会有这样那样的问题,但只要方向对了,就不会南辕北辙,总会到目的地的。
也基于这样的认知,我们在实施微服务的时候,基于相应的理论学习和经验实践,我们把微服务的生命周期过程关注的重点事项定义为:微服务规划、微服务构建、微服务协同、微服务测试、微服务部署发布、微服务运营、微服务治理、微服务下线。每项任务侧重点不同,实现的能力不同,共同完成微服务生命周期过程。

一、 微服务生命周期

采用微服务不仅仅是写几个微服务就万事大吉了,微服务的部署、运营,微服务之间的调用、协作,微服务版本管理、上线下线,以及微服务体系的规划、每个微服务的设计构建、测试,都是微服务体系中重要的内容。也是基于此考虑,我们将微服务整个生命周期过程任务事项梳理定义为规划、构建、协同、测试、部署、发布、运营、下线和治理等:
h41is5744ktk

h41is5744ktk

  • 微服务规划是在决定采用微服务之后对现有业务流程进行梳理,根据自身技术能力和特点选择合适的设计和构建方法论,规划和构建微服务所需资源和基础设施平台等。
  • 微服务构建是基于微服务设计和构建方法论,逐步提取微服务组件服务,分步骤的实现整个微服务体系建设。
  • 微服务协同设计,是指微服务间基于彼此的联系和依赖实现服务间调用和协作,共同完成业务应用逻辑功能。
  • 微服务测试是微服务在测试环境构建测试域,利用测试挡板工具或服务完成微服务的各项测试,以满足业务部门提出的功能、性能、部署、安全等各项需求。
  • 微服务部署是微服务达到生产就绪的条件下部署到生产环境,为微服务正式发布做好准备。
  • 微服务发布是完成生产验证后正式对外发布服务,使服务可用。
  • 微服务运营是向业务应用客户提供正常的服务的过程,记录并监控运行情况、计量计费、维护资源、修复缺陷、安全保证等。
  • 微服务下线涉及微服务的版本管理、下线计划、下线提醒、替代方案、接口停用、服务关闭等事项。
  • 微服务治理则是为保证微服务整个生命周期过程中微服务的正常运营协调所需人员、流程、资源及所采取的措施等,比如提供微服务接口服务、微服务安全、微服务监控以及微服务生命周期管理等,进行流程、人员、工具之间协作的一种方式。

微服务生命周期中的微服务规划、微服务构建、微服务协同、微服务测试、微服务部署发布、微服务运营、微服务下线、微服务治理等事项侧重点不同,实现的能力不同,共同完成微服务生命周期过程。同时微服务生命周期过程也是DevOps贯穿的过程,微服务的弹性、灰度、监控、治理、管理等需要依赖容器等基础设施平台的支撑。这样可以充分利用各种技术的优势来提升IT对业务变化的响应能力。

(一) 微服务规划

基于前期的学习、交流和研究,以及对自身技术实力、对业务流程的理解和认知,选择合适的方法梳理业务流程,梳理数据交互,尝试业务分解,规划业务微服务。微服务规划直接会影响到后期微服务的设计和构建,对微服务设计思想的认知和对业务流程理解的深度以及微服务设计方法直接决定了微服务设计的质量。所以我们认为如果没有这方面的专家指导微服务规划和设计,没有相应的基础设施支撑,不能自主管控微服务的生命周期,不建议轻易采用微服务架构。
我们认为IT系统建设已经过了走一步看一步的阶段,当前需要对IT技术的选型和基础平台建设做出一个相对中长期的规划,这类似于战略层级,方向性的错误损失可能无法弥补。这也是我们关注规划的原因之一。
微服务规划的关键是对业务和技术的理解。梳理业务流程的目的也是为了加深对业务的理解,业务流程伴随着数据流程。但往往一个现实的问题是技术人员对业务都是一知半解,但业务系统建设通常由技术人员主导,所以结果往往不令人满意。所以我们强调从业务和数据的双向融合,业务从上而下,数据从下而上,根据业务考虑数据的产生节点、数据量、数据变化频率、SLA(负载、响应时间、最大并发请求)、存储需求、网络流量、局限性等,从而可以方便的在下个阶段构建数据物理模型。当然这并不容易,既要求对业务有深入的理解,也要求对技术有深厚背景和广阔知识面,能自主把控的专家参与并指导。
微服务规划也是基于资源整合的考虑,人力、技术、设施、工具、数据等等若能整合在一起,可以集中力量发挥整体优势。当前软件发展已经从单体-集成阶段过渡到了融合-平台阶段,服务化特别是微服务的思想使单体软件系统逐步消亡,代之以统一化平台,比如基础设施资源虚拟化平台、开发托管运维PaaS平台、业务数据中台和服务中台等,这些平台也不是彼此独立,而是协同成为一个支撑企业业务的大统一平台。平台以组件服务如同积木可插拔的方式构建,其扩展性、弹性、可维护性、开放性、标准化、可替换性等都是当前单体或集成软件无法满足的。
在融合-平台阶段,前台不同业务组、业务团队的运营需要通过云计算的多租户机制来保证,权限隔离、资源隔离、可扩展性、自治等由基础设施平台来支撑。可便捷的实现资源的重组和调配,敏捷响应业务快速变化需求。

(二) 微服务构建

规划做好了,构建就容易多了。首先提取公共的组件,比如权限、配置、日志、监控告警、报表等。然后使用选择的微服务设计构建方法从上到下,从业务到技术;从下到上,从数据到技术,设计构建出满足业务需求的微服务。比如DDD和主数据设计方法。微服务设计、构建或拆分的关键在于正确的理解业务,识别新建业务应用或重构单体应用内部的业务领域及其边界,识别数据生成、流动、变化、存储、来源的节点。构建主数据模型,基于模型构建业务组件微服务,再基于业务流程构建其他的微服务组件。
不同问题需要不同视角来观察理解,需要全面的认知,我们不认为一种方式可以万能,所以可以尝试不同的方法来构建,从不同的视角、不同的层次来验证微服务构建的结果。
微服务实现可能更多需要考虑业务数据:数据量、数据存储、数据变化、频率以及局限条件等,然后确定数据库层实现或存储设计:单表、分区、分表、分库、分数据中心、分地域等,微服务逻辑的实现方式会影响到微服务的配置、部署、扩展、弹性等。

(三) 微服务协同

我们一再强调微服务构建工具并不重要,微服务生态环境才是需要认真考虑的事情。微服务协同就要微服务在整个生态环境中高效合作完成业务需求。

(四) 微服务测试

测试是微服务生产就绪前的重要工作之一。测试是很繁琐但又是很重要的工作,特别采用微服务之后,如果无法实现测试的自动化或DevOps,不只是影响交付效率和质量,其繁重的测试工作也会让测试人员不堪重负。特别众多微服务不同版本之间的协同测试,靠人力可能会捉襟见肘。我们可能不得不借助工具,在测试环境根据测试的场景自动构建测试域,利用测试挡板工具模拟调用的服务,自动生成测试用例,由容器云平台提供资源支持,实现弹性伸缩、灰度发布、负载均衡等能力,完成微服务的功能测试、集成测试、性能测试等要求。同时检验部署、扩展、安全、日志、监控告警能力等。

(五) 微服务部署

为支持不同的开发语言和开发框架,我们要求开发交付的标准是可用的满足功能、性能、弹性、轻量的镜像,镜像仓库是各个环境之间的媒介,是微服务在不同环境发布和部署的起点。通常DevOps流程实现镜像安全检查、导入导出、镜像同步、镜像部署、微服务配置、微服务注册、微服务API管理、微服务发布等,由容器云平台提供微服务部署管理和治理能力。
可生产部署的微服务我们要求是生产就绪的。微服务生产就绪要满足功能、性能、弹性、高可用、容错、日志、监控、文档可用等能力,根据业务场景的要求支持不同的部署方式。

(六) 微服务发布

微服务部署之后,完成生产验证,通常可以通过API网关对外发布API接口服务。在服务目录或者API Portal上进行浏览查看或测试。
微服务发布可能会有灰度的场景需求,也就是对于发布的新的版本功能引导部分流量过来,以便用实际的业务流量数据检验新的版本功能的正确性,确保整体业务应用的稳定,在初始灰度验证的时候若有问题,可以及时调整,以减少影响,若没有问题则逐步扩大流量,直到最后接管全部流量。

(七) 微服务运营

API网关是微服务架构下重要的基础组件,利用API网关可以完成微服务的认证授权、访问控制、安全机制、路由、过滤、映射、转换、流控、熔断等非业务逻辑功能,也可进行服务请求统计分析、计量计费、生成报表、实现API经济,可以和容器云平台结合更好的实现微服务的治理。
微服务运营要采取措施保证微服务提供的接口服务的正常运行,比如容错机制、负载均衡、备份、自动扩展,或者根据业务场景实施流量控制,或某些特殊情景下采取熔断机制等。
运营过程中出现的缺陷需要及时修复,通过的DevOps缺陷修复流程实现快速的迭代更新,保证业务应用不受明显影响。

(八) 微服务下线

随着时间的推移,微服务的版本可能会越来越多,不可能同时运营维护所有的版本,一些老旧的版本在运营一段时间之后就可能需要考虑迁移到新的支持版本,以减少维护工作量,提高收益率。
微服务运营可以采用产品运营的方法,在新的版本发布之后,经过一段时间稳定运行之后就不再更新维护旧的版本,建议用户逐步迁移到新版本。这需要定义相应的微服务下线规则、流程和方式。

(九) 微服务治理

微服务治理理论上贯穿微服务生命周期各个阶段,涉及人、组织、流程等。通常我们讨论的是微服务发布部署和运营运维阶段的治理能力,关注的更多是技术层面。我们讨论过用API网关实现微服务治理,还涉及微服务规范、接口标准、微服务注册、日志、监控、API管理等等,都是微服务生命周期过程中治理的内容。我们也探讨过容器云之微服务治理 ,这里就不再深入讨论。

二、 DevOps协作

历史总是惊人的相似!很多技术思想也是相通的。DevOps是为了增强不同团队之间的协作,以高效地工作,微服务协同是协调微服务之间的协同合作。微服务是构建业务应用的基本单元,业务应用生命周期过程也就是DevOps贯穿的过程,协调相关的人、组织、流程、资源、工具,采取有力的措施来保障业务应用的研发、测试、部署、发布、运营等高效执行,满足快速变化的业务需求的要求,对市场需要快速响应,或者引领创造新的市场需求。

三、 容器云基础设施平台支撑

站的高看的远。基础设施平台的高度决定了其上托管运营的业务应用的敏捷度。微服务虽然不是必须要求容器云等基础设施平台,但有这样的平台将有助于提升业务应用的敏捷度,提高对业务变化的响应能力。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

6

添加新评论0 条评论

Ctrl+Enter 发表

本文隶属于专栏

最佳实践
不同的领域,都有先行者,实践者,用他们的最佳实践来加速更多企业的建设项目落地。

关于TWT  使用指南  社区专家合作  厂商入驻社区  企业招聘  投诉建议  版权与免责声明  联系我们
© 2019  talkwithtrend — talk with trend,talk with technologist 京ICP备09031017号-30