华为内部如何实施微服务架构?基本就靠这5大原则
副标题[/!--empirenews.page--]
《华为内部如何实施微服务架构?基本就靠这5大原则》要点: 随着业务的发展,代码量的膨胀和团队成员的增加,传统单体式架构的弊端越来越凸显,严重制约了业务的快速创新和敏捷交付.为了解决传统单体架构面临的挑战,先后演进出了SOA服务化架构、RPC框架、分布式服务框架,最后就是当今非常流行的微服务架构. 微服务化架构并非银弹,它的实施本身就会面临很多陷阱和挑战,涉及到设计、开发、测试、部署、运行和运维等各个方面,一旦使用不当,则会导致整个微服务架构改造的效果大打折扣,甚至失败. 本文从微服务的生命周期全过程,阐述微服务架构的改造如何实施,以及如何避开各种陷阱,提升实施效率. 注:本文内容是华为近几年来的服务化经验分享实录,如果你看的不酸爽,可以直接调到文末报名我们的线下活动,9月华为的同学会做一个线下的workshop,限额80人! 在实施微服务架构改造之前,我们的产品线遇到一个很大挑战,就是需求的交付周期越来越短,采用的传统MVC单体架构越来越难满足特性快速交付和上线的需求.传统的电信项目,团队规模往往都非常大,甚至会跨地域.跨团队、跨地域的分布式协同开发,代码的重用和共享是个难题. 例如我们的支付功能需要新增一个限额保护,短短十几行代码的一个小需求,评估之后竟然需要9个星期才能上线.原因就是限额保护功能需要同时在9个不同的功能模块中修改,新增900多个测试用例用来做全量的回归测试,示例如下: 通过对已有的MVC单体架构进行分析,我们发现主要存在如下几个问题:
以上问题的应对策略,就是服务化. 首先,需要对业务进行拆分.当业务量大了以后,特别是当不同的功能耦合在一起的时候,任何一个地方的改动都是非常困难的,必须对业务进行拆分,拆分的策略有两种:
其次,要做好微服务的分层:梳理和抽取核心应用、公共应用,作为独立的服务下沉到核心和公共能力层,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求. 完成服务的拆分和分层工作之后,就会涉及到分布式的部署和调用.如何透明化、高效的发现服务,需要一个服务注册中心,通过服务化和订阅、发布机制对应用调用关系解耦,支持服务的自动注册和发现. 服务化架构的演进历史在实施微服务架构之前,我们一起回顾下服务化架构的演进历史. MVCMVC架构大部分人都用过,它主要用来解决前后端、界面、控制逻辑和业务逻辑分层问题.比较流行的技术堆栈就是Spring + Struts + iBatis(Hibernate)+ Tomcat(JBoss). RPC随着业务特别是互联网的发展,业务规模的扩大,模块化逐步成为一种趋势,此时解决模块之间远程调用的RPC框架应运而生.RPC需要解决模块之间跨进程通信的问题,不同的团队开发不同的模块,通过一个RPC框架实现远程调用,RPC框架帮业务把通信细节给屏蔽掉,但是RPC框架也有自身的缺点. RPC本身不负责服务化,例如:服务的自动发现不管、服务的应用和发布不管、服务的运维和治理也不管.没有透明化、服务化的能力,对整个应用层的侵入还是比较深的. SOASOA服务化架构,企业级资产重用和异构系统间的集成对接,SOA架构的现状:在传统企业IT领域,主要是解决异构系统之间的互通和粗粒度的标准化(WebService).互联网领域,提供一套高效支撑应用快速开发迭代的服务化架构.例如各个互联网公司自研或者开源的分布式服务框架. 微服务架构首先看一下微服务架构的定义:微服务(MSA)是一种架构风格,旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦.它有如下几个特征:
微服务架构的实施过程中,首先遇到的最大的难题,就是它的拆分原则. 微服务拆分原则:围绕业务功能进行垂直和水平拆分.大小粒度是难点,也是团队争论的焦点. 不好的实践
建议的原则
(编辑:源码门户网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |