恒丰银行的发展战略意图是如何更好发挥金融媒介作用，整合金融服务资源和能力并与社会经济活动、大众生活场景相结合，实现社会多方参与协作的业务模式创新。恒丰银行突破物理网点的限制，面向细分客户群体的不同需求，有针对性地设计产品和业务流程，并以数字化运营为基础，充分发挥移动互联网络的优势，为客户提供便捷个性化、智能场景化的创新金融服务。唯有如此，才能在激烈竞争的金融市场存活并获得发展，atv直播，才能扬长避短实现弯道超车。

行内业务发展对 IT 系统建设提出的总体要求是“打造数字化驱动的智慧银行”，从 IT 架构规划和实施的角度，体现为如下几点：

充分利用云计算技术的优势，打造灵活高效并支持弹性部署的软件服务基础设施，支持高并发低延迟的移动互联场景应用需求，支持银行业务重心从线下到线上的转移，满足客户通过各种移动设备和自助机具获得良好服务体验的需求。

打造基于大数据技术的数字化运营体系，实现海量数据的自动化获取、加工处理、深度挖掘，并运用数据智能技术构建恒丰银行的“智慧业务大脑”，实现智慧网点服务、智能风控体系、智能获客与产品个性化推荐、实时的业务分析与决策支持。这也意味着一笔简单的线上客户交易，后台发生的事会越来越复杂，除了传统的交易帐务处理之外，还可能涉及到客户线上操作行为的采集、交易反欺诈引擎的规则判断和模式计算、交易完成后个性化的产品推荐和业务提醒、基于地理位置的生活场景服务推送；与此同时，客户实时业务视图在后台自动更新处理，不同的业务部门按照各自管理视角定制的实时业务分析看板也要重新计算和刷新。

坚守银行系统运行安全可靠的底线，在积极实现业务创新的同时，提供稳定可靠的服务质量。如在应对“双十一”购物狂欢节等特定的交易峰值是能保持稳定的服务能力输出；局部的程序缺陷造成的影响能有效隔离和自动修复，不好出现全局性的服务可用性问题。

InfoQ：恒丰银行在设计微服务架构初期，有什么样的考量，需要规避哪些可能存在的坑？

曾光尧：企业应用软件架构经历以 TCP/IP 网络通信编程为特征的 Client/Server 模式、以 IDL 接口描述语言为特征的分布式组件对象架构（DCOM 和 CORBA 为代表）、以 WSDL/WebService/ESB 为特征的 SOA 面向服务架构，一直进化到 Reactive/ 容器化 /DevOps 为特征的微服务架构。每一次应用软件架构的变化，都号称解决了以前的问题，简化了应用的开发，但对于大多数程序员来说，好像都是痛苦地被裹挟到这个软件进化的洪流，不得不适应主流技术架构的变化，在这个过程中的一知半解往往会引发无法预见的问题。

从我个人的角度看，这 20 多年应用软件架构变化主要有如下动因：

简化和屏蔽复杂的底层网络通讯细节，增强网络服务的可管理性和位置透明。

将越来越复杂的现实应用程序分拆为更小的软件部件，不断弱化部件之间的耦合度，降低部件的开发难度，优化它们组合成完整应用的实现形式。

将解耦后的软件部件部署为分布式轻型化的组件服务，增强组件服务的自治性、容错性，更好地实现分布式并行处理能力。

微服务架构在恒丰银行被采用的原因，主要因为当前应用的复杂度和应用服务的弹性部署要求。通过将大的单体应用系统分拆为多个松耦合、可独立运行的微服务组件，可按业务和技术职能划分给更小的团队独立开发，减少代码变更对整体应用的影响，对不同的应用部件按需弹性配置硬件资源。

容易陷入的认知误区是：

认为应用程序只是换了一种运行容器或基础设施，大家还是按照单体应用程序的构建形式开发和部署软件。

把握不好微服务的粒度划分原则。粒度划分过细导致微服务过多，会增加跨网络的接口调用成本和降低响应速度，加大运维部署成本和资源分配难度；粒度划分过粗，甚至退化为原有的三层结构，不容易隔离业务应用之间的影响，为出现性能瓶颈的软件部件分配更多的硬件资源。

考虑到我们需要采用 Reactive 微服务架构去解决传统架构存在的问题，我们还是从技术和业务两个维度去切割微服务：

用异步化编程模式包装各种网络服务为基础的微服务组件，如数据库服务、FTP 服务、MQ 服务等，这些服务局限在应用内部调用，一般不对外开放。这种做法可以简化网络服务调用的复杂交互控制细节，为后端网络服务的压力负荷管理提供可能性。

(责任编辑：本港台直播)