“Weniger aber besser（少而优）”是德国工业设计大师 Dieter Rams 崇尚的设计理念，也是乔布斯“至繁归于至简”的精髓所在。

关于架构，是不是越复杂越好呢？从各大金融案例来看，恰恰相反，简单才是硬道理。这也正是微服务能够流行的原因，市场上出现的服务架构如 EJB、SCA、Dubbo 等，相比微服务来说他们的功能更完善，但因为它们过于复杂，所以都没有微服务这么深入民心。

目前，微服务架构已经在金融企业范围内实践应用，伴随着系统不断的优化，企业会选择在原有基础进行改进，或者开发更多适合企业业务的新架构平台，这也许就是简单框架流行的本质。

本文就围绕微服务架构在恒丰银行的使用案例，采访恒丰银行科技开发部资深软件架构师 曾光尧老师，请他谈谈微服务架构给恒丰银行带来了哪些收益，以及恒丰在微服务架构上做了哪些研发。

InfoQ：曾老师，您提到说，恒丰银行开发团队自己研发了很多自适配的服务，是因为传统技术架构存在性能瓶颈，这里可否详细的介绍一些性能瓶颈有哪些？

曾光尧：银行传统的应用服务架构大多数是基于 J2EE 体系的，在大家熟悉的 Tomcat、JBoss、WebLogic 等应用服务容器上开发部署，应用软件通过较流行的 Spring/Struts/Hibernate 等技术框架实现对象容器化管理、MVC 分层、数据对象映射等基础能力。大部分的应用服务容器都是传统的多线程系统架构模式，通过服务线程池调度实现对外部请求的响应。由于操作系统线程切换代价较大等原因，在传统多线程架构下单个节点能够同时服务的客户端有限，并发服务能力始终没办法获得大的提升，在我们实际生产环境中，单节点应用服务的 Qps 一般在 1000 以内。

通过学习国外先进网站的应用技术架构特点，和现有的架构做比较，我们可以发现传统多线程服务架构不能有效发挥当前 CPU 多核的硬件优势，存在如下缺点：

在网络多路复用 IO 技术选择上，大部分应用服务容器采用 select/poll 机制，对操作系统内核的负担较重, 容易遭遇 C10K 问题（即单个服务器节点客户端连接不能超过 1 万）。而在目前移动互联应用场景下，手机设备往往需要和后端应用服务器建立 WebSocket 这种全双工的长连接，以提升客户交互体验，这就对单台服务器能连接的设备数量提出了更高要求。

一个客户端请求在执行过程中独占一个服务线程，应用服务容器同时处理的请求任务数取决于线程池大小，我们往往需要配置较大线程池（一个 CPU 逻辑核对应 10 个以上线程）才能实现更大的并发处理能力。但在高并发场景下，线程数越大意味着操作系统的线程切换管理负担加大，从而减少硬件资源的有效利用率，增加服务响应时间，降低服务器负载容量。

线程之间共享资源操作需要借助锁机制，而在高并发场景下，锁冲突会加剧，从而影响业务逻辑的执行效率和线程资源的使用效率。

在客户端请求执行过程中只能采用同步（阻塞式）IO 机制，在商业应用中，服务器线程大部分时间是花在 IO 等待上面，比如本地文件读写或网络服务等待上。

传统应用服务容器本质上还是单体应用，高度容错的分布式并行处理编程困难，业务逻辑难以拆分成多个并行处理子过程，无法有效利用多节点和多核的 X86 服务器集群硬件优势，业务逻辑越复杂对客户端的响应时间也越慢。

综上所述，我们认为传统服务架构因为网络多路复用 IO 机制、线程调度、锁资源竞争、同步 IO 等因素，难以有效利用 CPU 计算资源和实现业务逻辑的并行化处理， 整体服务承载能力有效，不能满足移动互联应用场景高并发低延迟的技术能力要求。

InfoQ：简单介绍一下恒丰银行的业务特点是什么？对整个公司的 IT 架构有什么特殊的规格？

曾光尧：恒丰银行是 12 家全国性股份制商业银行之一，经营的金融业务种类齐全，近年来业务发展稳健快速。恒丰银行致力于做“知识和科技的传播者、渠道和平台的建设者、金融综合解决方案的提供者”。提出了“四轮驱动、两翼齐飞”的经营策略（“四轮”是指企业金融、金融市场、零售金融、移动金融业务，“两翼”则是投资银行和资产管理业务），依托金融云平台和大数据平台，实现龙头金融、平台金融、家庭金融、O2O 金融等四大金融创新业务模式，打造数字银行、交易银行、银行的银行，力求为客户和社会提供效率最高、体验最佳的综合金融服务。