【Techo大会】用1614带你看微服务架构的最佳实践和发展趋势

文章目录

• • 一个Case -- 金融行业微服务落地案例分析
  • 六大原则 -- 微服务架构的六大最佳实践原则
  • • 一、怎么样来处理遗留系统？
    • 二、如何做恰当粒度的拆分？
    • 三、如何扩展微服务系统？
    • 四、如何提升研发效率？
    • 五、如何取舍分布式事务？
    • 六、如何做监控和运维？
  • 一个方法 -- 微服务架构实践的通用过程方法
  • 四大趋势 -- 微服务架构的发展趋势
  • • 趋势一：响应式微服务
    • 趋势二：服务网格与云原生
    • 趋势三：数据库网格与分布式数据库
    • 趋势四：单元化架构
  • 传送门

读者们可能有的是企业中的技术骨干或者技术业务负责人，会进一步思考微服务架构在落地过程中是否有最佳实践可以参考和遵循。

作者：秦金卫

来源：腾讯云中间件公众号

秦金卫，目前是Apach Dubbo和Apache ShardingSphere 这两个顶级项目的PMC项目管理成员。这两个项目一个是用来做微服务的，一个是在做微服务和底层做数据本身的拆分，做数据本身的分布式事务和数据中间件。过去几年里面也做了不少微服务底层中间件和大规模复杂业务系统的微服务项改造，带领团队做了很多金融行业微服务架构的案例，也作为专家顾问参与一些互联网公司的案例。

本篇文章分享的主题总结一下1614，1个Case，6个原则，1个方法，4个发展趋势。大概2019年初的时候，我跟几个朋友写了一本书叫做《高可用可伸缩微服务架构》，我那本书里面也系统全面解释了一下到底微服务是什么，有什么样的一些技术特点，围绕dubbo和spring cloud怎么做微服务等等。本篇文章主要分享我在实践中总结的一些有参考意义的Case和最佳实践的原则，以及我对微服务整个发展趋势的大方向判断。

一个Case – 金融行业微服务落地案例分析

大家都知道我们国内，像金融行业和其他强烈依靠IT发展的企业，IT的发展阶段大概就三个：

• 第一个阶段是1999到2008年，主要是从传统的分布式记帐到实现电子化信息化过程。
• 第二个阶段是2008到2014年，这个阶段主要是网络化移动化，实现了我们所有人都可以通过移动设备接入到移动网络，使用系统服务。
• 第三个阶段是2014年到现在，是数字化智能化过程。在这个过程用户数据越来越大，反过来可以基于我们的数据来推动整个业务的发展，实现技术驱动运营。

我本人有幸在第一个阶段的十年，完成了大学学业，参与到国内银行业的金融IT建设。在这个阶段，有幸见证很多银行从电子化到系统化集中的过程。

第二个阶段一边做银行的事情，一边还参与了淘宝等互联网技术，参与到他们的一些架构项目中，也参与了一些网络化和移动化的过程。

总观下来这三个阶段，随着IT系统的发展，金融行业数据量和客户量越来越大。整个金融行业的系统也越来越复杂，对系统性能的稳定性、一致性、可用性、扩展性、可维护性，这些非功能性的要求也越来越高。

拿我之前负责的一个金融核心案例来说，当时我接手的时候系统规模比较大，有10多条业务线都在上面运做，大概功能模块有几百个。这个系统活跃用户量在100万以上，整个用户量接近1亿。每天产生的交易订单大概2-3亿单，这个规模大概是淘宝、京东每天交易订单数的10倍。

整个系统的订单处理能力、帐户和资金的结算能力都受到严重的制约，稳定性非常差，经常崩。交易金额也比较大，每天交易金额超过100亿美金。系统存在着非常严重的稳定性问题，研发效率不高，十几个BU业务条线，天天吵来吵去，所以各方都很不满意，包括客户的满意度也比较低。

在我接手之前，团队也尝试过做一些拆分和微服务改造。当时规模比较小，没有业务参与，做的简单粗暴，就把核心系统拆了一下。然后很快发现控制不住了，平均一个人维护1.5个子系统，整个系统的稳定性能还不如之前好。我们做微服务改造过程中，先把所有的业务运营、产品、技术拉齐，确定整体的业务中台化建设和如何改造这个最大的目标，把整个系统拆成前台、中台、后台。

前台是金融前端2C业务，天天在变。这个东西就不适合像以前一样放到核心业务里面去。像以前做传统的银行业务一样，很多中小银行的业务往核心放不了，就放到前置业务上。我们做了细分，把系统分为前台、中台、后台，后台是基础设施，保证整个系统最低程度的稳定性。在中台也分出来拆分，分为三层，最外边是API接入层，后面两层是业务中台和技术中台，这两个是微服务的核心。我们聚合了很多基础的业务单元，技术中台主要是服务治理和服务网关。

基础设施，当时整个的可靠性大概只有2个9，不到3个9，但是我们的业务系统想达到4个9怎么办？我们需要中间的系统中台层做大的改变，用它来支撑上面不会受到底层基础设施的影响。整个金融系统安全合规稳定，这一块是核心，所以当时我们引用了很多的策略，做了很多系统的稳定性建设。好在团队之前有很多谷歌、亚马逊专家做相关方案的建设，我接手两年前，他们就开始做稳定性相关的准备工作。

接手后我拿到两三年前所有COE故障报告，有多少ABC故障，怎么发生的，产生的原因等。通过这些东西就可以把所有历史发生的故障统计出来，那些系统、那些人，那些团队，如果发生故障是哪个环节出现了？通过这些去优化整合团队，优化我们的技术和优化我们的流程，把很多问题从根本上解决掉，流程的问题归流程、人的问题归人、技术的归技术、管理的问题归管理，这一块做好之后，降低了99%不稳定因素。

上面服务化的东西，需要有一个稳定的技术基座做支撑，所以我们夯实了底层，基础设施建设方面要有新的急速思想来解决原有问题。

• 第一层是数据库，中间有一段时间数据库大到没法备份，总出现长时间的同步延迟，如果那个时候处理不当，就会出现很多的问题。然后通过垂直+水平的多次拆分数据库，把整个的容量降下来，然后才能做备份。

• 第二层是消息中间件和内存中间件。业务对交易的低延迟很敏感，但是之前的核心交易都是基于数据库和磁盘文件，导致延迟很高。这里通过引入消息中间件做了交易流程优化，同时把系统原先各个节点的交互，进行引入内存化处理，最终延迟降低了一个数量级。

• 最后再引入容器化和自动化的策略，降低人工操作，逐步提团队的技术成熟度和研发成熟度。毕竟之前吃亏的经验教训就是：整个系统研发成熟度跟不上，大家还在传统时代，你给大家搞点高科技东西大家做不出来。

在这个过程中，我们引入了一些数据中台和数据治理，给数据做分层，因为每天的数据量太大了，我们把数据分为热数据、温数据、冷数据、冰数据。热数据放在关系数据库，温数据放在非关系数据库里，冷数据按照各种要求先放在那儿存起来，冰数据直接干掉不要了。
整个改造完之后，吞吐量提升50倍以上，延时由原来的600ms降低到30ms以内。整个的系统维护成本急速降低，业务对接上的时间减少80%以上。以前对接一个业务需要两周，系统处理完后只需要两天，整个系统稳定性基本能达到我们的预期要求，达到4个9。整个系统改造完之后有了一个质的飞跃。

六大原则 – 微服务架构的六大最佳实践原则

在我带团队做微服务的这个过程中，总结出来微服务架构改造的六个最佳实践原则：

一、怎么样来处理遗留系统？

整个基础架构发展都是从简单到复杂，一个系统比如前面做的微服务改造，都是系统发展到一定阶段，业务层面很难处理，数据量很大，出现问题Hold不住了才去改造。对于这种遗留系统的改造，怎么样去做才是比较好的实现方式？我总结出五条四十个字：

1、功能剥离、数据解耦

不仅改应用系统，按照功能和垂直能力进行拆分到业务中心来。同时，数据库要做拆分，我见到很多研发团队只是把系统应用集群部署，改为我按照业务能力拆分几大模块，但是数据库还是一大坨。这样数据库没有拆分，所有的压力还在数据库里，受数据本身耦合的制约。

2、自然演进、逐步拆分

先拆系统里最影响稳定性或者是业务需求最急的那10%、20%，先拆分掉。不管是一刀切成两块，还是先切一个不重要的小功能，其实都是可行的办法。但是就这业务需求，或者稳定性需求里，最火烧眉毛的地方下手，最能见效果。也可以提升所有参与方对后续改造工作的信心。

3、小步快跑、快速迭代

每拆分一小块，这一小块就可以单独维护了。之前在一个案例里，有个模块发展了很多年，这个模块有10万行代码，发现老系统没法改动，删掉不出问题还好，出问题扯不清楚了，那就让它在里面待着。我们拆分出来重新写了一遍，很快写完了，采用了不到8000行代码。

4、灰度发布、谨慎试错

这个也很重要，通过引入各种发布方式（滚动，灰度，蓝绿，金丝雀，等等方式），保证发布的稳定可靠。我们发现80%的故障都发生在系统发布或变更的时候，就像飞机出事情一般都是在起飞那前5分钟，和落地的前5分钟。

5、提质量线，还技术债

每个系统的质量一定是随着长期稳定的发展，慢慢降低的。在每拆分一部分的时候，我们可以把它切出来，把它弄干净了，再看怎么弄。这样就可以把以前的质量补上来，把以前的技术债补上来。

二、如何做恰当粒度的拆分？

拆分原则是：高内聚低耦合、不同阶段拆分要点不同。根据实际的需要拆分以后可能中间需要磨合，在第一个拆分大的周期内，我们发现有些东西拆分不合理后面再补就行了。

三、如何扩展微服务系统？

这里有一个扩展立方体的概念。所有的系统扩展，都可以归到这个立方体里，立方体有三个方向XYZ轴。

• X轴是水平扩展，其实就是机器复制。我们前面加个F5和nginx，就可以把业务系统无脑的复制N个系统进行负载均衡，把压力平摊掉。

• Y轴是功能解耦，我们可以把用户、商品、交易、支付这些不同的模块全部拆分开，变成独立的系统，首先拆分的过程中就把系统做了第一步扩展。拆分完以后，就可以按照不同的系统特点，去扩展不同的系统内容。

• Z轴是数据分区，要切分数据。这个里面有两个含义，第一个是水平区分，对所有的数据做无差别分片、分区这种拆分。第二个是很多时候我们发现系统里面整个数据的使用不是平均的，它是有倾斜的。比如说系统里VIP的用户和大户的交易，我们可以给VIP单独做一台机器处理他的请求，按照用户数据本身的特点和标签做扩展。这一块也是我们后面要说的单元化架构的基础。从这个扩展中，我的经验是要加强特性开关，让新的和旧的加一些容错设计达到兼容，使得我们的系统上线以后，如果有问题可以随时的按照特性开关，把流量驳回到老的系统，或者逐渐把流量迁移到新系统。再稳定一段时间，都稳定了再把老的下掉，中间有一个双核心并存的过程。

四、如何提升研发效率？

以前没有拆分之前单个系统测试好做，部署、运维都好做，拆分以后系统变大、变复杂了。对开发、测试、部署、运维，都是一个大的挑战，这个时候需要比较强的自动化处理经验能力。

五、如何取舍分布式事务？

从最开始数据库支持的XA，到后来业务侧的TCC、SAGA、AT等。TCC业务是三个独立的小事务，不是一个大事务。这三个单独又有联系的小事务对业务的设计是有很高的要求的，也就导致了所谓的业务侵入性，现阶段我看到很多项目用错了。

SAGA事务模式，就是直接做各个跨库的业务，出了问题就挨个的去做撤销的操作，偏没有分布式事务的方案，跟很多年前没有这种分布式事务概念之前，大家一直用的业务补偿/冲正的模式是一样的，所以目前金融行业大家用的最得心应手。

AT是自动化的生成反向操作和SQL，比较智能化，但是现阶段还不是太成熟，复杂的逻辑可能会处理不了。这几种都是数据库之外，在业务侧去控制的柔性事务机制，也叫最终一致性事务。实际上关系数据库甚至一些中间件比如MQ，都可能内置支持了XA这种强一致性分布式事务。从十来年前起，在金融交易等一些需要保证强一致性的地方，这种技术用的最多。

六、如何做监控和运维？

监控运维涉及微服务的可观测性，也是一个非常有意思的话题。监控一方面要支撑我们的业务运行情况，一方面要配合技术基础建设。配合业务这一块，之前我最大的感触是我们的监控不仅要从技术和系统指标来做，同时要从业务指标考虑。很多时候我们发现业务部门和客户的抱怨，系统哪些东西出问题了，我们一看所有的系统技术指标是好的，肯定不是我们的问题。这个时候技术和业务就发生严重的冲突和混乱。

然后，我们系统里做的各种各样操作，都会直接把系统的业务指标加上去，先从业务指标去看问题，然后从技术指标找线索。同时做好容量规划、报警预警、固化运维流程。我们之前发现很多技术人员如果他去负责和主导上线，一定会想着把上线过程中出现的问题都解决掉，让它一次上线成功。然而我们的经验是上线过程中出现问题，最好的办法是还原到上线前的版本，把当时的数据保存下来然后慢慢再分析。故障处理做好处置方案。我们故障有天灾人祸，天灾避免不了。系统像一个人，时间长了一定会出现问题，所以出现各种流量的异常、崩溃可能是一个正常的现象，我们一定要积累足够的解决措施和经验去处理。

我们经常说，一次停机维护，如果我们有预期的，先告诉所有客户，那这就是一个故事。如果我们发现有问题，不停机维护，等到某个时间点突然宕机了，这就是一个事故。

一个方法 – 微服务架构实践的通用过程方法

说了这么多的微服务东西，微服务到底在具体项目里怎么做的呢？我总结了一共八步，前四个步骤是准备阶段，后四个步骤是实施阶段，然后可以再返回到准备阶段，持续的迭代这过程：

• 第一步是调研，先了解系统现状和各方诉求；
• 第二步是明确核心的问题和改造目标；
• 第三步根据目标去做好改造阶段和计划，一蹴而就是不现实的，特别是系统涉及到上千人在一块工作的时候完全不现实。
• 第四步是协调系统相关团队和资源，前四步合起来就是准备阶段，准备阶段四步跟实施阶段四步不一样。

后面四步是拆分、部署、治理、改进，从技术监控运维到整个的制度和流程，大家所有的配合是不是OK的，如果有问题不管是哪一块的问题再进行改进，然后循环迭代的过程，这样就慢慢把一个大的业务系统，全部改成微服务。

这个过程中会有人问我，你给我推荐一下我在哪个点用什么样的方法去处理问题？你跟他说不用追求系统最新最好的技术，你追求和目前你的团队成熟度相符合的技术就可以了，特别是金融行业要做自主可控做开源这一块。

四大趋势 – 微服务架构的发展趋势

最后，给大家介绍一下微服务的发展趋势。从单体架构到垂直架构到SOA到微服务。

微服务的概念比较早，从2011年就有，大家众所周知的时候是在2014年，国内开始从2014年、2015年做第一波微服务，2016年有响应式微服务，现在比较火的是服务网格的概念和云原生的概念。

微服务架构发展如火如荼，目前主要有四个大的发展趋势。

趋势一：响应式微服务

响应式微服务起源于响应式宣言和响应式编程。其中即时响应性，是说不管是系统出现什么样的情况，只要没有宕机，就一定要给用户提供响应性的服务。简单来讲，就是我们越来越意识到了系统就像人一样，一定会出现头疼发烧等之类的问题，那么在出现问题的时候，我们是直接宕机，还是在一定条件下提供部分的服务能力。

可恢复性和弹性，可弹性就是可伸缩可收缩，另外消息驱动，系统跟人一样，我们需要做一个选择，你这个完全不提供服务了，还是现在在有限的能力范围内提供服务。我经常举的例子，一个系统在整个系统保护和限流这一块有三个层次：

• 第一个层次是所谓的流量的控制，比如说我们按照单位时间的次数和访问数据量，带上权重的方式来限制。

• 第二个就是服务降级，如果做所有的业务做不来，我专门留给大家取现金。

• 第三个是整个系统过载保护，这个系统早就扛不住了，一个银行的网点，本来下午5点下班，我现在3点就下班了，也是过载保护了。过程中整个系统是不宕机的，保留了最小服务的运作，这就是说它的可控恢复性就跟人一样。

趋势二：服务网格与云原生

在过去的 2 年里，服务网格（Service Mesh）绝对是一个大家耳熟能详的热门话题。不同于常见的 Apache Dubbo 或者 Spring Cloud 微服务方案，服务网格是说把微服务里面各种跟业务无关的策略，统一的从业务系统部署到这个节点，从进程拿掉存在基础设施，也就是Sidecar，微服务和微服务之间都通过本地的Sidecar通信，Sidecar通过控制面板控制策略规则，这是微服务网格。

这样，我们就把系统划分成了业务服务所在的数据平面，以及控制节点所在的控制平面。从而在这个心的结构上，微服务节点只需要关注与业务逻辑本身。

趋势三：数据库网格与分布式数据库

同样地，我们把这些概念应用到数据库领域，就产生了一个新组件，我们可以先叫它 Sharding-Sidecar。这样业务系统就可以不用去管理数据是什么协议，具体在什么地方，而仅仅需要把所有的数据都当做是本地数据，向 Sharding-Sidecar 组件申请使用即可。所有跟数据库本身相关的配置，所有的数据质量、安全、流控和治理的策略，也不需要业务系统直接感知。

相应地，我们也可以把 Sharding-Sidecar 加入到数据面板，把我们的分布式数据库治理和 UI 加入到控制面板。同时，我们可以把对业务系统完全透明的数据库节点比如一批 MySQL 实例，作为一个新的层，叫存储面板。此时，一个完备的云原生的数据库中间件解决方案，就产生了，我们称之为数据库网格（Database Mesh）。

趋势四：单元化架构

很多大型机构没法一步到位直接去做微服务，那么我们可以在微服务改造过程中相当于把原来的大件变成迷你的版本，甚至是部分正好是自洽的形成一个闭环，分发在不同的数据中心里面。

下图是最近我作为专家顾问参与的目前四大国有银行其中一家，他们做的整个单元化架构。底层用到的PaaS层（腾讯的TSF+TDSQL），这些大家应该都知道了，再上一层用我们自研的服务治理层和单元化架构层。

我们总结一下，现在微服务的发展趋势，从微服务到服务网格到响应式微服务，到数据库网格和云原生，再到现在做的一些事情，把微服务架构思想和经验跟现在的一些大规模的金融行业业务案例相结合，比如单元化架构。

我们下期再见！

传送门

• Techo大会现场直击：微服务架构的最佳实践和发展趋势
• 了解更多微服务相关资讯：腾讯微服务平台 TSF
• 反馈交流您的宝贵意见：腾讯云中间件问答社区

标签：服务,1614,系统,看微,业务,拆分,架构,Techo,数据库
来源： https://blog.csdn.net/qq_36668144/article/details/112848946