华为内部如何实施微服务架构？基本就靠这5大原则

《华为内部如何实施微服务架构？基本就靠这5大原则》要点：
本文介绍了华为内部如何实施微服务架构？基本就靠这5大原则，希望对您有用。如果有疑问，可以联系我们。

随着业务的发展,代码量的膨胀和团队成员的增加,传统单体式架构的弊端越来越凸显,严重制约了业务的快速创新和敏捷交付.为了解决传统单体架构面临的挑战,先后演进出了SOA服务化架构、RPC框架、分布式服务框架,最后就是当今非常流行的微服务架构.

微服务化架构并非银弹,它的实施本身就会面临很多陷阱和挑战,涉及到设计、开发、测试、部署、运行和运维等各个方面,一旦使用不当,则会导致整个微服务架构改造的效果大打折扣,甚至失败.

本文从微服务的生命周期全过程,阐述微服务架构的改造如何实施,以及如何避开各种陷阱,提升实施效率. 注：本文内容是华为近几年来的服务化经验分享实录,如果你看的不酸爽,可以直接调到文末报名我们的线下活动,9月华为的同学会做一个线下的workshop,限额80人!

在实施微服务架构改造之前,我们的产品线遇到一个很大挑战,就是需求的交付周期越来越短,采用的传统MVC单体架构越来越难满足特性快速交付和上线的需求.传统的电信项目,团队规模往往都非常大,甚至会跨地域.跨团队、跨地域的分布式协同开发,代码的重用和共享是个难题.

例如我们的支付功能需要新增一个限额保护,短短十几行代码的一个小需求,评估之后竟然需要9个星期才能上线.原因就是限额保护功能需要同时在9个不同的功能模块中修改,新增900多个测试用例用来做全量的回归测试,示例如下：

通过对已有的MVC单体架构进行分析,我们发现主要存在如下几个问题：

• 研发成本高：代码重复率高,需求变更困难,无法满足新业务快速上线和敏捷交付.
• 测试、部署成本高：业务运行在一个进程中,因此系统中任何程序的改变,都需要对整个系统重新测试并部署.
• 可伸缩性差：水平扩展只能基于整个系统进行扩展,无法针对某一个功能模块按需扩展.
• 可靠性差：某个应用BUG,例如死循环、OOM等,会导致整个进程宕机,影响其它合设的应用.
• 代码维护成本高：本地代码在不断的迭代和变更,最后形成了一个个垂直的功能孤岛,只有原来的开发者才理解接口调用关系和功能需求,新加入人员或者团队其它人员很难理解和维护这些代码.
• 依赖关系无法有效管理：服务间依赖关系变得错踪复杂,甚至分不清哪个应用要在哪个应用之前启动,架构师都不能完整的描述应用的架构关系.

以上问题的应对策略,就是服务化.

首先,需要对业务进行拆分.当业务量大了以后,特别是当不同的功能耦合在一起的时候,任何一个地方的改动都是非常困难的,必须对业务进行拆分,拆分的策略有两种：

• 横向拆分.按照不同的业务域进行拆分,例如订单、商品、库存、号卡资源等.形成独立的业务领域微服务集群.
• 纵向拆分.把一个业务功能里的不同模块或者组件进行拆分.例如把公共组件拆分成独立的原子服务,下沉到底层,形成相对独立的原子服务层.这样一纵一横,就可以实现业务的服务化拆分.

其次,要做好微服务的分层：梳理和抽取核心应用、公共应用,作为独立的服务下沉到核心和公共能力层,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求.

完成服务的拆分和分层工作之后,就会涉及到分布式的部署和调用.如何透明化、高效的发现服务,需要一个服务注册中心,通过服务化和订阅、发布机制对应用调用关系解耦,支持服务的自动注册和发现.

在实施微服务架构之前,我们一起回顾下服务化架构的演进历史.

MVC

MVC架构大部分人都用过,它主要用来解决前后端、界面、控制逻辑和业务逻辑分层问题.比较流行的技术堆栈就是Spring + Struts + iBatis(Hibernate)+ Tomcat(JBoss).

RPC

随着业务特别是互联网的发展,业务规模的扩大,模块化逐步成为一种趋势,此时解决模块之间远程调用的RPC框架应运而生.RPC需要解决模块之间跨进程通信的问题,不同的团队开发不同的模块,通过一个RPC框架实现远程调用,RPC框架帮业务把通信细节给屏蔽掉,但是RPC框架也有自身的缺点.

RPC本身不负责服务化,例如：服务的自动发现不管、服务的应用和发布不管、服务的运维和治理也不管.没有透明化、服务化的能力,对整个应用层的侵入还是比较深的.

SOA

SOA服务化架构,企业级资产重用和异构系统间的集成对接,SOA架构的现状：在传统企业IT领域,主要是解决异构系统之间的互通和粗粒度的标准化(WebService).互联网领域,提供一套高效支撑应用快速开发迭代的服务化架构.例如各个互联网公司自研或者开源的分布式服务框架.

微服务架构

首先看一下微服务架构的定义：微服务(MSA)是一种架构风格,旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦.它有如下几个特征：

• 小,且只干一件事情.
• 独立部署和生命周期管理.
• 异构性
• 轻量级通信,RPC或者Restful.

微服务架构的实施过程中,首先遇到的最大的难题,就是它的拆分原则.

微服务拆分原则：围绕业务功能进行垂直和水平拆分.大小粒度是难点,也是团队争论的焦点.

不好的实践

• 以代码量作为衡量标准,例如500行以内.
• 拆分的粒度越小越好,例如以单个资源的操作粒度为划分原则.

建议的原则

• 功能完整性、职责单一性.
• 粒度适中,团队可接受.
• 迭代演进,非一蹴而就.
• API的版本兼容性优先考虑.

（编辑：PHP编程网 - 黄冈站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!