转型求通—微服务架构的最佳实践和发展趋势（通过落地案例分析）

微服务

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

今天给大家分享的主题总结一下1614，1个Case，6个原则，1个方法，4个发展趋势。微服务是什么？刚才冠军讲得很清楚了。大概2019年初的时候，我跟几个朋友写了一本书叫做《高可用可伸缩微服务架构》，我那本书里面也系统全面解释了一下到底微服务是什么，有什么样的一些技术特点，围绕dubbo和spring cloud怎么做微服务等等。

今天主要分享微服务这本书之外，我在实践中总结的一些有参考意义的Case和最佳实践的原则，以及我对微服务整个发展趋势的大方向判断。

• 一个Case -- 金融行业微服务落地案例分析
• 六大原则 -- 微服务架构的六大最佳实践原则
• 一个方法 -- 微服务架构实践的通用过程方法
• 四大趋势 -- 微服务架构的发展趋势

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

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

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

 

我本人有幸在第一个阶段的十年，完成了大学学业，参与到国内银行业的金融IT建设。在这个阶段，有幸见证很多银行从电子化到系统化集中的过程。 第二个阶段一边做银行的事情，一边还参与了淘宝等互联网技术，参与到他们的一些架构项目中，也参与了一些网络化和移动化的过程。

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

 

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

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

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

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

</