课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
随着互联网的不断发展,微服务开发在许多开发需求场景中得到不同程度的应用,下面我们就一起来了解一下,在不同层面上的微服务开发表现形式。
在容量规划层面,单体应用时代只需针对单个应用的访问量和实际接口性能决定要不要扩容,拆分为微服务之后需要考虑每个服务的容量规划。刘凡建议,整体需要基于服务类型、团队规模和技术栈进行规划。先,不同的服务类型存在一些标准规则,比如大数据分析引擎可能需要遵循实时数据分析原则;其次,如果团队规模在五到八人之间,微服务不建议拆分得太多,否则运维、管理、更新都很难安排出人手;后,微服务应用达到一定规模之后就很难通过纯手工的方式进行管理,需要云平台和容器化技术的加入以帮助大容量微服务生命周期管理。
在服务聚合层面,主要涉及微服务的编排或者组合。在某些场景中,拆分后的微服务也需要彼此协作。刘凡表示,这种情况比较推荐常见的典型架构,比如通过API网关将微服务接口开放给客户端,客户端选择需要调用的接口根据逻辑拼装好数据,附加上相应的权限能力来访问微服务。同时,也可以选用一些编排工具,比如Spring家族里面的SpringCloudDataFlow(文末附具体介绍),通过这样的数据和流式编排工具完成微服务之间的组合或者聚合。
在服务治理层面,除了可以通过轻量级通讯协议将内部接口开放给外部系统外,业界目前比较流行的技术还包括Istio等。Istio是一种ServiceMesh的技术,是一套无代码倾入性的微服务治理且更符合运维人员习惯的解决方案,它使得微服务治理完全放到平台层进而实现全面的DevOps成为可能。虽然Istio目前还不太成熟,只发布到1.1版本。随着越来越多的企业和用户为之贡献,该技术会逐渐走向成熟并终用于更大规模的生产环境。
在微服务测试层面,刘凡表示,软件工程的质量保证是整个交付过程的重要衡量标准。因此,Pivotal推行测试驱动的实践方法,通过单元测试覆盖基础的业务领域功能;在微服务之间会采用API接口测试,基于API优先的云原生要素,采用如SpringCloudContract的契约测试方法,或基于API文档进行Mock测试。在交付阶段,Pivotal还会进行端到端的测试,而此时需要搭建测试环境。在测试环境搭建和版本升级时,推荐使用回归测试的方法。相较于传统应用的本地环境,微服务通常利用云平台自动化搭建测试环境,根据不同微服务的版本组合提交时会利用蓝绿发布、灰度发布、A/BTesting等方式进行测试。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。