我所遇见的微服务演进这十年

阅读字数: 1951 用时: 10分钟

嘉宾简介

王晔倞，现任职好买财富平台架构部技术总监。负责好买中间件及平台化的研发及运营，团队管理和实施重大技术决策。2011年在大智慧担任测试负责人期间，针对互联网产品技术核心和重点，DevOps的倡导者与实践者，曾建立大智慧数据平台“云测试平台”。2013年加入好买财富，参与了整个公司应用和技术架构变迁，参与很多和系统建设，辗转过不同的业务团队，对技术与业务都有一定的深入了解。

摘要

如今的微服务生态百花齐放，新的关键词不断涌现，而这都得益于“互联网+”在中国这十年的蓬勃发展。有人说微服务概念不断兴起，是不是意味着SOA重要概念企业服务总线ESB的死亡呢？它们是否是两个矛盾的选择呢？

早在十年以前，微服务这样的设计思想就在各大系统中运行或被灵活运用，IT系统或IT平台也伴随着互联网和移动互联网的盛行，海量的用户一次又一次的在微服务的道路上摸索与洗礼着。好买财富平台架构部技术总监王晔倞希望通过这次分享，与大家聊聊，在这十年间所遇见的微服务架构演进历程中的挑战与实践。

津津乐道的微服务究竟是什么？

关于微服务常见的四个问题

我们使用微服务的目标就是降低成本，提高效率，屏蔽调用（跨进程）复杂。RPC的职责是远程调用，它基本上等同于本地调用，分布式服务的一种表达方式。也就是说RPC并不能代表微服务，RPC的微服务是一种实现基础。

SOA属于企业领域，微服务则是基于互联网领域。企业之间的业务比较复杂，需要靠SOA去解决它的问题。而互联网拼的是快，所以会出现微服务的概念。SOA大部分概念是基于企业服务总线。微服务是架构思想的角度，是SOA互联网化的隐身。

微服务架构能更好地帮助实现系统和每个服务支撑的一种独立扩展。使用微服务框架，帮助你的服务能够得到更适合于服务资源需求的硬件资源。耦合度松不松，关键看你的系统纵横向怎么拆分，业务层级如何分层。

系统服务化不代表需要治理，如果是单独的模块，而且调用少，服务治理将显得笨重。如果单个模块被其他多个模块依赖，或单个模块需要做主备或者负载均衡，需要对各个服务做治理。服务规模大了才需要治理，并需要“带有服务治理功能的框架”，dubbo就是其中之一。

我眼中微服务

微服务是“互联网+时代”催生的一种设计思想和理念，并非什么高大上的技术。

微服务不是一场技术革命，它其实是一场对人的革命。

微服务给业务带来福利的同时，却给传统测试和传统运维带来了一场“革命”。

不同时期的服务，不同目标的追求

①“IOE”时期 - 面向单一的项目化客户群

我们当时和国内知名的金融公司有一个CRM系统项目。在整个系统和SOA微服务实现的过程中，CRM是一个非常好的体现验证。因为CRM中有大量以客户为维度的相关服务建设。

我们来看当时的技术基因是什么。

Oracle，这个项目里有1000万用户，每日批处理在三个小时内要完成。

Weblogic只要稳定就可以了。

IBM Power需要AIX玩得溜，出问题能迅速解决。

EMC是良好的存储方案，让它能快一些。

决定因素很重要。

能力：“超级”技术个体，它对单个的技术个体要求极高。

共用：丰富多彩，而且好用的开发组件。

业务：快速理解需求，不需要抽象。当时“IOE”时代对于服务化的概念，要求的是解决业务本身，不需要过多的去技术地深入。

编码：快速敲打键盘，最好写个生成器。

②“SOA”时期 - 面向多元的产品化需求源

随着客户增多，从项目化转变为产品化。

SOA最大的价值在于用一套系统、一套代码，在快速的配置化和非开发的一些技术动作上，能够同时满足十个客户的不同需求，这叫面向服务。

③“服务化”时期 - 面向独立的互联网业务线

多条业务线需求不同，小步迭代，快速试错。遇到这样的情况，就要求服务化。

服务框架给我们带来什么呢？

首先应用开发很简单，数据模板化。

其次就是技术栈多样化，利用各自的特点解决问题。

独立资源扩展，可按业务线自动化横向扩展。

可用性较高，具有多层级及冗余的技术保障。

但这样的架构也让我们失去了一些东西。

运维成本居高不下，矛盾日益剧增。

技术栈较多，给（持续）部署与（快速）排障带来了难度。

过多的链路，数据一致性。

未使用虚拟化，交付速度大打折扣。

传统金融服务在微服务转型过程中的那些事

为什么要转向微服务？

业务需求和用户行为互联网化了，交付与排障要求速度要快。

传统行业转微服务难在哪？

业务驱动性极强，历史孤岛多，资源投入少，全产品的业务复杂性。

目前给运维带来了什么？

服务之间的依赖，排障效率的提升，服务水位分析。

目前给研发带来了什么？

可以向测试“甩锅”，只需要关注业务本身，技术栈单一。

设计思想

运营：透明部署、持续交付、统一监控、统一配置。

平台：容灾/降级、负载均衡、灰度管理。

框架：RPC开发框架、中间件无缝连接。

资源：快速扩展、容器化。

总结

做个微服务平台其实不难，但上微服务平台，就好比西天取经。

设计思路是核心，devops和docker是工具、是手段。根据自己的业务去选择。长路漫漫，大家要在实践过程中自己去体验。

我的演讲到此结束，谢谢大家！