韩欣：企业微服务技术中台落地实践

5 月 25 日，互联网架构技术沙龙圆满落幕。本期沙龙特邀请腾讯的技术专家分享关于技术架构、落地实践案例、无服务器云函数架构、海量存储系统架构等话题，从技术角度看架构发展，为开发者们带来丰富的实践经验内容，深度揭秘技术架构。下面是韩欣老师关于微服务和中台的概念，及其落地实践经验的总结。

今天我讲的方向三个：一是整个云计算技术架构的演进；二是怎么理解中台；三是分享微服务技术中台的落地实践经验。

什么叫做微服务？这是 Martin 提出来的一个概念，它是一种将应用构建成一系列按业务领域划分模块的，小的自治服务的软件架构方式，倡导将复杂的单体应用拆分成若干个功能单一、松偶合的服务，这样可以降低开发难度、增强扩展性、便于敏捷开发，及持续集成与交付活动。如何界定：小、独，还有要做一个事情，完成单一的业务，单一的功能要拆分出来，因为如果耦合在一起就影响到另外一个模块，还有就是持续交互和敏捷，怎么去定义？多大算小？亚马逊以及国外的架构师由 2—Pizza 团队端到端负责一个或一组服务，大小是合适的，区别于传统单体应用，各个模块、组件或动态库集成在一个大进程中的运行。刚刚张老师分享互联网架构原来的技术和转型，我想讲一下微服务架构在传统企业里面特别明显，原来传统的 IOE 架构是什么样的？所有的应用最开始在 IOE 时代业务应用和数据库是在一起的，它的特点是什么？我的业务逻辑只会跟数据库交互，所有的复杂东西我把我的复杂逻辑在数据库内解决了，每个都是单一的，业务之间比较庞大，现在有很多公司在使用第二种架构方式，就是 SOA 的架构，它已经微服务化了，但是它的特点是调用和服务的提供者，需要和企业服务总线关联上，ESB 成为瓶颈：无论在性能上还是成消耗上，ESB 都会导致瓶颈出现。

架构的进化，最开始我们做单体架构的时候，1990 年 J2EE 就是把业务逻辑分为表示层、业务逻辑层、数据访问层，之后慢慢做一些拆分，以 SEB、SOAP 为代表，到现在容器、云化、敏捷、DevOps 联系在一起。为什么现在需要做架构？

一是互联网的高速发展，导致传统的企业，比如说政府、银行要做很多的架构演进。比如说一个客户，他原来是做保险的，保险的业务可能不是特别复杂，为什么现在要做微服务化？因为它的用户变了，原来是自己的业务员，现在把保险卖到互联网上，我在小程序、淘宝各个互联网入口都有我的用户，用户可以直接买，用户的群体发生变化以后，现在给我们要求是每秒要达到几万，以前一秒十笔，所以带给我们的用户群体庞大。二是敏捷开发，这是非常强烈的刚需，我们有一个客户他的痛点就是十点之前微软给我搞的架构，现在要改一个东西，要六周全部上线，因为所有的点要布到，达到的价值就是持续迭代和价值特性的小批量快速交付。现在我们也进入云化，基础设施服务化、自动化，降低应用部署，升级和管理成本。互联网的架构相对于传统的很多企业，包括政府的机关银行比现在好几个时代，我们很多搞互联网的同学，觉得好像没有特别的挑战，如果你去传统企业看一下，感觉还活在上个世纪，你想像不到现在很多企业还这样，很多时候云计算给大家带来价值，我们可以推动技术的变更和发展。

刚刚讲的架构方面，我本人其实对一些现在云计算的发展趋势一些演进，从云计算基础来讲三个方面；一是 IaaS 层，比如说应用、数据、中间件等等，往上是 PaaS 层，很多我觉得 PaaS 越来越成为一个重点发展的方向，最后是 SaaS，比如说智能客服等等都算是。现在更多的企业还有做一些 SaaS 化的应用。

越往上其实对业务性是越多的，关联性越强，但是越到下面通用性越好，对我来说很简单，都是标准化了，再从另外一个来看，越到下面，它其实同质化越重。

微服务只是架构的理念，容器在微服务里面非常好地把微服务的概念落地，因为它就是一处产生多处运行，微服务其实是架构层面的，是从上而下演进，我们强调的是架构设计上面的概念，容器是资源层面的，我们原来可能计算在 IaaS 上，之后往 PaaS 延伸的，把资源进行隔离进行调动，那虚拟机是不是也要到服务器的级别？慢慢延伸出来容器，再讲一下微服务与 RPC 框架，其实每个公司都有 RPC 框架，微服务概念没有兴起之前都已经存在了，它跟微服务有关联性，但是没有从本质上改变微服务的架构，其实微服务强调的是一种服务治理，Devops、敏捷，RPC/REST，我们原来做框架的就是强调协议是不是做到相互兼容，还有通讯协议、同步异步、多线程多进程、高性能。

讲一下微服务与 ServiceMesh，大家觉得 ServiceMesh 是不是代表将来的？ServiceMesh 是在容器的基础上，因为容器有一个特点，它还是在资源管理调度方面，对业务是无感知的，越到上越有附加值越高，ServiceMesh 在容器的基础上演化出来的技术，想去帮业务做一些更多事情的，在微服务上的管理平台，但是这个技术有没有问题？其实有一些问题，一是比较局限，目前社区里面的 ServiceMesh 技术，只是支持一些协议而已，对业务还是有一定的限流性。

从我们的理解来说，中台在干什么？中台这个概念也是我们的友商最先提出来的，从我们的角度来讲，中台区别于后台，传统上我们中台其实并不是一个单独组织，是区别于后台系统和前台系统提出来的，后台是为了我们做功能而生，后台只是为了功能而生，中台是在前台之下，后台之上，我是解决业务问题的，为了实现功能而耦合在一起，把它变成一个平台化的东西，这是我们对中台的理解。举个例子，我为什么要做中台这个事情？比如说电商的秒杀，大家都觉得做一个秒杀系统有很多的难度，挑战点在哪？一是如果现在要做秒杀系统会不会被现有的网站的其他业务有冲击，一个秒杀系统会不会拖垮整个业务系统？二是高并发的情况下对数据库产生压力怎么去做管理？三是下单，秒杀就是十个单，十个东西可以秒杀，秒杀的时候怎么去控制？四是怎么做秒杀开始？五是下单控制，很多时候你说在页面上控制，很多人肯定绕过你的页面，六是下单前置检查，七是定时上机，八是减库存和秒杀数据怎么一致性？但是具体到一个大的零售电商公司，它的挑战是什么？

秒杀只是促销的模块一部分，还有对帐，从百货转到服装，对公司来说是有难度的，后台系统要重写一套，原来可能是针对百货分类做了一些处理，但是换到服装这个品类就不行了，可能有些产品满足不了，这个东西站在业务角度把这个东西剥离出来，很容易就做了，对大公司来说是一套系统。

其次，为什么要做中台？目标其实为了协助业务落地实施、改造、试错、转型，收益，提升组织效率，降低系统成本，围绕业务组织，进行可复用能力的有机整合。不管是什么中台、业务中台，都是围绕着业务给他们提供可复用能力，降低成本，提升我们的效率。

这是中台三个层次，一是云基础设施层，中间是技术中台，这一块也是我们最擅长的，三是业务中台，面对不同行业的应用，可能有行业同学他们会主导做这个事情。这是一个传统的零售中台架构，网关技术中台、服务器各种业务中心，典型的一个零售业务中台架构。

技术中台怎么解决问题？设计一个技术中台，可能要服务限流，服务路由，分布式缓存等等能力，这些能力怎么组合起来，做一个中台应该包括两部分，就是管控和支撑，支撑就是你的能力，对应一些后端，比如说限流服务器这些能力就是支撑，管控就是管控一些管控平台，我把它控制好，包括框架和运行时；所以我们把它叫做框架和运行时和管控和支撑。

技术中台面临的挑战，框架、运行和支撑怎么联合起来？这个就像造飞机一样，涉及到很多的技术上的挑战，从我综合来说两个词可以总结，一是化繁为简二是深度抽象，把很复杂的东西尽量简单化。

TSF 是什么？是一个基于微服务的提供面向业务开发过程整体技术解决方案的技术中台，TSF 微服务技术中台核心能力，微服务框架、DeVOPS、服务化能力支撑、数据化运营、服务治理。这个中台我们设计的架构，一个合理业务的中台架构是什么样的，看看我们画的图：外网用户、第三方、CLB、APL GATEWAY。目前来说现在有很多企业也面临选择，到底用虚拟机还是容器，我觉得要解决业务开发过程中一系列面临的业务问题，我们都提供统一分装。再下面是支撑能力，种种技术统一分起来，出了问题可以快速分析。其实现在我们进行的微服务框架分了几部分，例如微服务 C 可以去调用 Spring MVC 应用 D，两个不同的程序包提供一个能力的，不管你是什么语言，什么样的资源，都可以。

微服务治理有几方面，一是服务鉴权，就是服务能不能调？A 能不能调动 B，还有就是服务某个条件的用户能调用 B 的某个接口，配备就可以达到这个能力。二是服务路由，路由是抽象概念，我们提供两种方式，权重路由和标签路由，还有多机房的路由优先。三是服务限流，我针对一些重要的接口可以设置限流能力。四是服务容量，设了四个级别。五是服务熔断，目的是把一些故障的信息踢掉，服务的隔离就是服务故障时候把整个服务全部屏蔽掉，配合容错可以做一些事情。接口隔离是另外一个纬度，如果基于实际的级别统计，有时候是接口本身有问题，可以针对接口可以去做隔离，针对每个接口有不同的失败率；我只把这个接口屏蔽返回确认就可以。六是服务降级，两个纬度，API 纬度和标签纬度。

下面讲资源管理的概念，这里用了几个概念，容器，另外一个是命名空间，支持命名空间是跨集群的，两个服务可以互相调用，部署组对于开发，如果传统上把一个架包部署在一批上，就要选一批；另外就是应用，做程序包管理，上了一些包还有一些配置。这是我们的应用管理的，批量部署、版本管理等等。还有分布式配置，配置版本管理、实时更新、灰度发布、多环境发布、动态配置等等。时间有限就过了。全局日志，还有所谓的 API 治理，要引入 SCK，只要加一个注解，就会自动扫描你的 API，文档生成等等可以做到自动化。

还有就是微服务网关，这是一个很重要的入口；还有分布式事务，现在业界事务的能力，一是消息队列的事务，就是很多时候我把一些事务在消息队列级别实现，还有 TCC 事务，就是在框架级别它可以解决什么问题。传统我们提供框架级别，它把事务分为三个阶段，只要三大逻辑实现就可以。FMT 事务，即框架托管事务，只要你连接的是数据库按照正常去写你的逻辑语句，有异常的时候我会把你从前到后所有的数据库，具体怎么做下面可以交流。某一个段出错我可以找出上下文给你抓出来，这是我们提供的整体能力，不包括这些，这是我们落地的项目，原开发效率提升 50%，业务可进行实时响应，日常升级，业务 7×24 不间断；还有中台技术的展望，比如说部署组染色，对我们来说灰度发布存在一个问题，我们怎么在流量的情况下让某些流量只流进 ABC，旧的不受影响，以及全链路压测，强弱依赖分析和慢查询分析，Serverless 支持，大屏运维能力。

好的技术架构都是能简单，快速，高效的解决实际业务问题的技术架构。技术架构从我角度来说是一个工具，技术就是一个工具，工具的目的是产生收益，是让业务获得更大的收益，我觉得能够快速高效简单的解决业务问题；只要贴合业务，根据业务快速解决业务问题的架构才是好架构，今天分享这么多，谢谢大家。

Q：您好，一直在说大中台的概念，我有点不太理解，怎么实现平台式的大中台？我们不是在代码层面实现的吗？

A：这就存在一个误区，我们很多传统写代码的，不应该是让开发用上，而是提供 SCK 保证你能用，而且做了高度的抽象，这些东西是不是继续往下抽象就看你需不需要，如果只需要一个数据存储，为了数据的读取效率，包括现在所谓的存储，那么只是写数据和读数据，性能的问题由其他人解决。

Q：服务框架应该也看看市面上的，您能讲一下哪些做得比较好？优点是哪些？

A：W 是优秀的框架，这得真正承认，不是说他做的代码写得多好，而是接口设计是非常优秀的，框架的层面我建议是区分两个流派，RPC 调试起来很痛苦，其实我建议是框架的选择，大家根据业务去选择，比如说你的业务只要是微服务化就可以实现。

作者介绍：

韩欣，腾讯云高级工程师，微服务平台，消息队列，API 网关等产品的负责人，负责中间件相关产品的规划，架构和落地实施。有超过十二年的研发架构经验，先后在腾讯、百度负责过腾讯广点通实时推荐系统，腾讯手机 QQ 空间，百度 im+即时通讯平台，百度知秋智能客服等产品的研发和架构工作。目前关注在云计算中间件相关领域，致力于整合 paas 技术资源，构建基于微服务的技术中台，为企业的数字化转型提供基础支持。

本文转载自公众号云加社区（ID：QcloudCommunity）。

原文链接：

https://mp.weixin.qq.com/s/u7p2_BZ7our2wg2yierK6g