▍写在前面
笔者来自中国电信集团下属支付公司甜橙金融，旗下涵盖翼支付、甜橙理财、甜橙征信，甜橙保险等多个品牌。近年来，甜橙金融底层技术架构逐步完善并完成了一次大的升级，作为架构升级的一个底层平台的设计参与者，笔者结合以往从业经验，简要谈下对于微服务的理解，以及对于服务架构选型如何同业务实际发展相结合等方面。
首先我们聊一下微服务，网上对于微服务的解释层出不穷，各种大牛都给出了一定的名词定义，这里不再赘述。笔者认为，微服务是一个思想，从最开始的MVC、组件式开发，到SOA思想、应用解耦，到现在的微服务、模块化，从最根本来说，一直秉承的是“每个人做自己该做的事情，整体协同达成最终目的”的简单道理。
关于“每个人做自己该做的事情，整体协同达成最终目的”，从一个公司的生命周期而言，它总是会经历初创期，动荡期，成熟期等不同的阶段，团队人员的发展也是一个从最开始的几个人到成几百上千人的过程，它的整体组织架构也会从开始的一个团队慢慢的演变成功能相对独立的小团队，最终井然有序完成公司生产经营工作。从业务系统而言，小到每个方法，每个类，大到每个应用，应该都能够找到一个纯粹的定义来解释它是做什么的，然后将整体有机组合，最终实现一个个的业务场景。
是什么推进了整体系统架构的演进升级呢？从公司组织者角度来说，系统就是一个工具，在系统能够服务当前业务场景的时候，它就是一个好的系统，当它不足以快速支撑公司业务发展或者当业务变更时，公司组织者才有可能会有动力来进行工具的更新换代，也就演变成了系统架构的升级改造。从纯技术角度来说，作为一群有修养的程序员，一直没有停下来技术探索的步伐，带着互联网思维下的社区精神，富有使命感技术团队的贡献，以及当前现实场景下的大流量刺激，使得基础通信组件在不断的进步，大应用集群的服务治理方案日渐成熟，自动化的系统运维的落地，以及监控手段的逐步更新，使得我们系统往微服务化发展成为了可能和必然趋势。
下面，笔者主要以在支付行业的一些从业经验，来聊一聊系统架构的三种形态。
▍一代架构
传说中的一个war包打天下，MVC思路构建系统，可能做得好的系统会在package方面做一些前瞻性的业务分离，这个时候的系统，外网进来直接到应用，应用直接访问数据库，内部网络没有一些应用间的通讯情况发生，做得更好一点的公司，可能会在核心敏感数据方面做一些应用级别的剥离，核心数据存储和外网中间再做一次防火墙的隔离，系统间的通讯多采用hessian、http、socket等。
那么，这种架构现在过时了么，笔者并不这么认为，对于初创型企业或者业务体系不复杂的，业务量不大的公司而言，让他们用大型微服务架构体系可行么？有这么多的人力和资源供给么？在这种情况下，一代架构就够了，它能够很简便的进行维护，十个人以内的团队就能够很好的进行维护，而对于发布需要停机的槽点，在业务场景很简单的时候我们可以通过程序员的业务低峰期发版来进行解决，业务稍微复杂的场景完全可以通过负载均衡（Nginx，F5等）来保持业务持续可用。
▍二代架构
一代架构随着业务的发展，各种风格的程序员不停的维护，系统的耦合性越来越高，维护成本越来越高，并且从业务角度来看，完全独立的业务在系统层面不停地互相干扰，掣肘着彼此的发展。此时，应用的业务化分离改造成为了必然，较为快速的迭代方式就是复制粘贴，单独部署，分别维护，俗称“烟囱化架构”。
我们都知道，一个系统整体的全新升级，是需要一个很长的研发周期和人力投入，而在这么长的时间周期内，我们的业务不可能存在停滞状态，在市场环境竞争如此激烈的情况下，业务停滞往往就意味着淘汰，那么，在一代架构慢慢的成为业务发展的瓶颈时，如何在业务发展和系统升级之间取得平衡？笔者认为，快速剥离业务耦合，支撑业务需求的变化，同步部署第三代架构是一个比较合适的方案，为什么这么说呢？首先，在一代架构成为业务发展瓶颈的时候，公司往往是具备了一定的市场竞争力和经济基础的，这个时候组建一个第三代架构的研发团队是可能的，其次，同步研发三代架构的过程中，分别部署，分别发展是能够很快迭代上线的，并且能够比较好的解决业务耦合的问题。当然，在分别部署过程中，肯定会遇到这样那样的问题，但这些问题是可以逐步改善的，这个时候需要考虑的更重要的事情是：在未来系统架构升级过程中，业务和数据的迁移问题，这部分需要资深架构师的前瞻性设计和大牛级运维的数据迁移方案。
▍三代架构
随着业务规模的逐渐扩大，业务模式的快速发展，一代架构也好，二代架构也罢，耦合度高，维护成本大，上线周期长等问题不可避免的会成为业务方、市场人员和产品经理的槽点。此时，基于高质量的RPC通讯组件、大规模集群化的服务治理方案、自动化运维体系及成熟的事中、事前监控解决方案下的微服务架构，成为一个必然的趋势。
三代架构下，笔者单从目前就职的甜橙金融集团下的3.0架构，来谈谈它是如何快速支撑市场业务发展的。
首先，作为互联网金融行业来讲，支付是最终的共性问题，而对于支付，简而言之一句话，“把某某某的钱通过什么方式给到某某某”。在基于这句话的基础上，建设一个基础的支付平台成为了非常有必要的一件事情，基础平台域应运而生，它对外提供基础维度（收单、代扣、充转提、代付等）下的支付解决方案。
在第三方支付场景下，我们将基础平台域划分了清分域，支付域，收单域，账务域和结算域，那么，我们是按照什么样的维度去进行架构分离的呢？
1：面向C端用户的，同时还需要第三代架构支撑的支付企业，基于复式记账的账户体系是一定需要的，而在这种情况下，作为纯粹的基础能力，账务域模块独立成为一个域就变得非常有必要，其中又可以拆分成基础账务核心、业务账务核心、账务查询、会计系统等。
2：第三方支付，永远存在的一个问题是对接银行，不同机构间，报文格式不一样，交互方案不一样，对账模板不一样。所以，一个对接第三方系统的清分域自然而然的就出现了，而在清分域中，我们可以按照功能分别拆分为清分交易模块、智能路由模块、清分对账模块、查询模块等。
3：微服务体系下，跨系统的事务一致性一直都是痛点，而在支付企业，数据安全和资金安全是排在所有关注点的首位，对接不同资金源（银行、营销、自有账务体系等）时，如何保证资金的安全呢，解决跨系统事务一致性的支付域很好的完成了它的系统职能和使命，内部按照模块可以划分为支付核心、支付查询、支付决策、支付收银台等。
4：底层基础平台归根结底是需要对外提供服务的，而封装基础支付能力，按照基础维度，提供基本的交易能力和交易解决方案，让交易域成为了整个基础平台的灵魂，按照内部系统职能，可以划分为交易核心（可以按照业务维度拆分成多个微服务）、交易查询，以及统一对外的交易产品等。
5：支付体系，商户最关注的永远是对账、资金划拨和资金安全，在这种场景下，对账域承担的职责就非常的清晰，我们可以按照不同使用场景分为结算中心，费用中心等。
其次，在基础平台域以上，对于不同维度的场景中，可能会有部分业务场景差异化问题，这个时候，位于基础平台上层的产品平台就有了存在的必要，它去提供该场景下的业务解决方案，屏蔽差异化数据和业务，同步使用底层标准解决方案。
然后，在产品平台之上，我们可以依据不同的业务场景，不同的交互方案，快速迭代一些新的业务产品，使用底层公用的基础能力，完成业务的快速上线，友好支撑业务场景，举个例子：在某一天我们可能多了一种新的收单交互场景（如虹膜支付），这个时候，我们只需要架设一个新的产品应用，完成差异化部分的兼容，即可快速上线。又比如理财业务新接了一种新的产品，完全只需要做好产品交互方案的整理，就可快速上线。
最后，整体微服务架构下的对外服务出口，协议转换、系统安全、流量控制，服务降级等大牛级应对大流量场景下的流量控制模块，MAPI是我们最终应用对外的最华丽的外套，它的存在，让底层的应用可以不用太多的关注安全，大流量冲击等场景，而将精力专注在自身所在的模块的业务实现！
▍写在最后
整体的微服务架构体系建设，永远少不了的是基础运维团队的核心力量，在一个系统架构的演进中，笔者认为，对外服务的前瞻性设计，是一个系统无感升级最为重要的一件事情，如果开放接口设计之初没有考虑整体性和兼容性，在做整体业务架构升级的过程中，我们总是被迫要做很多的适配层，这样大大降低了新的架构对于非技术人员的吸引力和认可度。笔者一直希望的事情是，每一位同道，在做企业级服务对外开放的时候，多想一步，那么，对于后来者而言，能够跳出“是哪个大佬设计出来的？怎么能有这么牛逼的设计？”之类的吐槽怪圈之中。
作者 | 郝捍东 七年金融IT从业经验，目前就职于甜橙金融信息技术部，主要负责甜橙金融第三代支付系统的架构建设工作，对于支付体系架构，有一定的个人见解。
