曾学海：感谢大家，刚才那个问题我觉得似乎就是为我这个话题开场的。大概去年年底的时候，短短几个月的时间，中国大的几家做PaaS平台的厂家都来找我谈合作。他们给我讲的内容和今天我在这个会场里听到的内容非常接近，他们给我介绍了他们的PaaS平台有多么强的产品、服务等等。我说听上去很不错，你需要我做什么？这些PaaS平台给我提了一个相同的问题，他们说我们的销售团队很强，他们可以把云平台卖给我们的客户，卖给银行、零售，但他们遇到一个问题，我们发现我们的客户的系统并没有在云上跑起来。意味着他们买我们的云，有可能两年以后我们这个云仍然没有产生价值，也就意味着这个生意可能做不下去的。他们提的问题是你能解决掉这个问题吗？
大概2014年的时候，ThoughWorks的首席科学家开始向这个行业普及微服务，过去两年我们做了很多这样的客户说微服务和云到底在业务系统中如何用起来，它需要什么样的咨询服务、实施、基础实施和管理。今天我会讲两个真实的案例让大家感觉到这样的场景是如何发生。
这两个案例非常有代表性，几乎是我在过去这大半年中看到客户的代表。第一家是银行，它在中国排名大概前20，不在北京，在南方。它这几年大量依赖线上渠道做生意，所以线下的网点人越来越少，所以线下网点逐步转向做高端理财和私人银行，零售业务都往线上改。它遇到一个问题，现在的系统跑在400机器上，现在这几年线下业务发展完全受制于系统的处置能力，这个系统能承载多少业务就只能做多少业务。所以它现在400这套机房的处理能力2015年左右已经接近极限了。它现在整个电子银行的覆盖率98%，零售业务占整个业务52%，他们的目标是继续提高零售业务的占比，私人贷款业务在整个贷款业务中占比40%。
2015年年底的一次座谈会议中网络金融部的总经理说，2016年希望重点做小微贷和消费贷。大家都感觉到2016、2017年小微贷和消费贷是非常火的一波浪潮，这个总经理说我要对接互联网的交易平台，比如某团网，某二手车交易平台，通过为这些交易方采集他们的流水信息、交易信息，来给他们放贷。可以部的总经理说我们400的系统是顶不住互联网的流量的，尤其这么多的小微企业。
首先做这一点要对数据中心做扩容，网络金融部中心说如果没有办法的话就做扩容嘛，现在我已经完全受制于400的能力了，我必须解决掉这个问题。2017年这个扩容完成了，花了一年时间，1.5亿，他们叫新中心。现在业务需求很旺盛，2017年年初整个小微贷、消费贷、零售金融是非常火爆的，几乎在二手车交易平台都是2017年年初开始起量。中心建成以后是一个新的AS400的中心，建成以后网络金融部的总经理发现他提了很多的IT需求，问题是几个月之后这些IT需求仍然没有上线，原因是这些系统一直都在开发。
新的中心就花了1.5亿，但在闲置，每闲置一个月就是浪费。网信部的总经理就觉得压力很大，花这么多钱没有看到效果，这时候就问科技部总经理为什么，说因为我们的IT需求挤压了大半年，我们都在搞新中心，现在我们的时间非常紧，为了满足你的需求我们已经强制要求研发部做96模式，IT团队必须敏捷，两周一个迭代必须解决你的问题。
2017年4月，这三个月的系统开发完成了，也上线了，但质量不好，出了很多的Bug和线上事故。网信办的总经理就说我的感觉不好，很担心有一天去央行、银监会做汇报，因为我们没有持续交付，所以Bug很多，现在做敏捷已经来不及了，不如花点时间把这个系统修好让它上线。2017年11月份系统终于稳定下来了，但迎来一个好的结果，第三季度的时候贷款业务开始明显增长，互联网带来了很多新的客户，他们准备在这个领域继续深挖。原因是什么？这些互联网带来的客户不仅仅是当地客户，因为它对接了一个全国性的交易平台，所以能在一个地区通过网络做跨地区的生意，这将突破以前线下渠道带来的限制。但科技部总经理说，我们现在不到一年的时间，但新中心的计算里已经被吃掉80%，明年我们有可能要再度扩容，他去询问了400的供应商，这个建设成本不是线性增长的，如果做第三个中心的话有可能是五到六亿。
行长说我们现在面临一个IT的黑洞，要么提业务就做这么多的量，要么每年让IT供应商吃掉我几个亿的利润，这个问题怎么办？科技部总经理说，我们现在核心的问题是我们最核心系统没有摆脱封闭式系统的依赖，只能跑在400上，一定要上云，而且IT相应性、可用性、开放性都需要提高，现在面临的问题是我不知道这件事怎么做，全中国现在为止只有一家银行宣称我的银行跑在X86系统上，微众银行。如果有一天新的银行，比如谷歌有一天做金融服务了，银行怎么办？竞争对手完全不是一个数量级上。他说能不能这件事上有一个整体的解决方案，或者你告诉我有哪些问题是我需要考虑的，能不能解决下来再说。
他有四个问题要解决：
1、软件架构。大家都知道一个小的互联网系统上云是很容易的，但如果我是一个很大型的国有企业，大型银行，不可能把我的系统全部端起来平移到云上，再落下去，这是可能的。而且我也不应该这么做，原因是我所有的系统都应该上云吗？结论显然不成立的，哪些系统应该上呢？这个问题应该怎么回答？这个迁移的过程，我怎么能逐步的完成，并且保证在每个节点有一个检查的手段告诉我现在的风险是多少，先不谈风险可控的问题，至少知道风险有多大。我现在的系统如果按这种方式拆一部分上云，我的系统支持我这样拆吗？
2、我应该建立一个什么样的云平台，云的架构应该是什么样的，如何避免我新建的云平台再次绑定在一个封闭的云上，我绑在400上和我绑在封闭的云上没有区别。现在国字型的企业都要求自主性、自控。如果我建一个混合云平台的话，应该如何混？公有云、专有云、私有云各有特色和限制。
3、未来数据架构是什么样的，未来所有的银行都一定要求业务数据要自主、自治，新的数据架构如何保障这一点？如何保证我的数据可以迁到云上？新的数据如何来管理、利用？这是我的数据架构。
4、安全架构。大家知道数据中心是很安全的，因为它有各种安全措施来保证，但是上云之后，无论上私有云、专有云还是公有云，它的安全级别和安全性一定赶不上数据中心的，但必须走这一步，如何规划新的安全模式使得既能利用上云的好处又能规避它带来的安全问题，加上各种不同国家的隐私法案越来越紧，一定有一个机制如果有一天国家继续收紧对数据安全的要求的话，我的系统保证是可控的，能快速相应这个改变，而不被停下来整改，这一个银行要面临上云要回答的四个问题。
如何解决？我们最后给了一个这样的解决方案，这是它的核心系统。首先第一件事。
2016年开始我们知道了如何对银行的核心系统做双模的建模把所有的银行系统分两部分，第一部分是非敏捷态业务，第二部分是敏捷态业务。
敏捷态业务的标准是，第一它需要提供互联网级别的高可用性，第二它需要提供高响应力，第三是需要提供一个复杂的可复用的场景。
找出这部分业务之后，我们要知道它的优先级是什么，看它业务的多变性有多大，复杂度有多高，改造成本有多高，当然这也要考虑业务部门的意见，说哪些要立刻实现。基于这个也排列出了优先级，之后识别出这三个是未来我们要第一批上云的微服务架构。
它要用到的工作方法是微服务的架构设计需要这个能力，微服务拆分的能力，这件事我们得到的结果是我们拆出了一系列可以被部署的微服务，它的边界是什么，它的职责是什么，它的内容是什么。下一步我们把这些微服务开发出以后，通过这种容器化的方式部署在它的PaaS平台上，
这个PaaS平台是它的私有云。我们选了三组微服务部署了三个Docker，这部分用到的是敏捷、持续集成、持续交付以及DevOps。
同时，我们怎么保证未来它的数据是可以被挖掘、重用的？我们建了一个数据平台。就是一些常见的数据湖、数据流水线、数据集和数据商店的技术，这些不多讲了大家都很熟了。它通过一个API的暴露运行在PaaS平台，它的工作方法是数据即服务，以及DDD领域建模，保证在PaaS平台上所暴露的服务全部遵循一套的建模方法和建模规范。解决什么问题？如果这样做的话，这个企业会有非常多的服务，如果架构规范是不一样的，接口规范是不一样的，未来开发团队如何使用这些API会变成一个非常复杂的问题。一致以后就很简单了，做一次培训大家就知道这些服务该如何使用。
下一步，是我们针对前端的应用系统所改造的，它主要应用是手机网银、小微贷和信用卡，三个应用是分开的。这一块做了一个BFF层，这些API需要被合并来应对前端的需求。数据这一块有一个明确的网关，因为数据是高度受限的。再往下是数据中心了，这一部分没有上云的。
数据如何分布？这一部分可以放到公有云上，可以由客户决定上公有云还是私有云，这部分的数据，页面的缓存数据和静态文件数据，这部分放在私有云上，强制要求使用私有云。这部分是交易数据和应用数据。这部分数据是放在数据中心的，这部分数据是账户的数据，会计的数据，身份数据，清算数据和报表数据。可以看出来，在每个云平台的层上都可以放这些数据，问题在于它对数据的敏感性和数据的颗粒度是不一样的，身份数据一定放在数据中心。通过这种方法他意识到系统要上云有了一套基础设施，应该是这样的架构，同时哪些系统应该上云，我有了一个方法。同时，在制定上云计划的时候，我有一个实施步骤，我做每件事的时候需要什么样的能力我也清楚了。这些能力谁提供？我可以去找，有些是PaaS平台，有些是我自己自建。如何应对国家数据安全的要求，我也大概知道的，所以就有了一个方法去摸索我将会面对什么样的问题。
这件事是我们今年年初的时候启动，到现在大半年的时间，现在有一部分微服务的API已经跑在PaaS平台，前面对接API，同时这部分有独立的数据库，通过一个比较挺难设计的数据回写机制保证它所产生的数据和在业务流程上能响应。它的BI报表逐渐向数据平台迁移，摆脱以前BI的系统。这是银行的客户。
接下来讲另外一个场景，这个场景比银行简单很多。这是一家电商，我在外面看到这家电商好像也有人来。是国内一家一流的手机制造商，大部分销量都是通过线上渠道，通过它的商城、天猫销售的，这几年它的业务增长速度非常非常快。同样面临一个问题，智能手机这个市场在中国已经逐渐饱和了，今年大家都能看到Q1、Q2智能手机的增速整个市场是放缓的，所以海外市场的重要性在不断提升。加上现在国家“一带一路”逐渐构筑这样的基础设施和经济环境，使得它开始考虑海外市场如何布局。
在2017年一个业务座谈会，业务线总经理说我们要推出一个新品牌的手机，公司希望这款手机主打东南亚市场，我重点考虑印度市场的电商渠道，我们不可能马上去印度去开线下门店，希望线上来做。希望以前的电商平台可以支撑未来业务全球化的事情，我可能要去东南亚、韩国，未来可能要拓展一些非洲市场等等。这个电商平台的负责人就说我们需要评估一下现在的电商系统如何支撑全球化，以前电商平台搭一个网站卖东西就可以了，没有想过支撑全球业务，也没有想过“一带一路”会给我们带来这么现实的影响。
如何评估这件事？这个电商平台负责人，把国内负责做电商的供应商全部摸了一遍，发现能提供这个解决方案的几乎没有。如果说有的话，通过阿里什么的，那需要绑定产品、绑定数据，他也不是很愿意。所以跟我做了一个谈话，我们发现他面临这么几个问题：
1、全球化的体验。系统需要考虑不同国家、不同地区的客户体验、风俗习惯，都不一样。同时，要保证品牌是一致的，而且这么多差异化的体验不可能都满足，因为我的建设成本是有限的，那么这个全球化体验的问题怎么解决。
2、数据架构应该是什么。我的企业需要遵循不同国家、不同地区的数据隐私法案，同时也要考虑虽然我遵循这些法案，但问题是企业总要做统一的管理，这个事情如何解决？
3、全球化的系统架构应该是什么。不同地区的业务流程存在很多的不一样，系统需要提供足够的灵活性，但同时我又希望尽量的统一管理，这样我的建设和维护成本是很低的。举个例子，电商里面你买个手机，需要开一张发票或者开一个什么样的票据，全球这么多国家每个国家开发票的流程、制度、法规都是不一样的，这个事情也是很复杂的。
4、全球化的运维，比如欧洲要求数据不能离开欧盟，我如何能适应当地的法规，而且很多地区会限制你只能用什么样的云，比如在美国不能用某些云，比如用微软、AWS云等等。如何保证我既能遵守当地的法律，又希望全球的运维是方便的，我用什么样的方法管理我的容器和线上系统，这是一个全球化电商要面临的问题。以前在中国做的所有的电商本质上没有真正彻底解决这些所有的问题。
我们设计了这么一个方法解决，它现在只有一个中国的数据中心，正在建的是新加坡的数据中心，未来还要建一个德国的数据中心。所以我们设计这个系统的时候，假设你在过三个数据中心，中国、东南亚和欧洲。基于这三个中心做了一个云管平台，对于这家企业他非常需要云管平台是技术中立，是要能自主的。在这个云管平台上搭载了一个Design系统，它其实是基于你的CMS搭建一个统一的用户体验的管理规范。同时这个云平台上建了一个容器管理平台，上面架了一层微服务平台。为什么需要微服务平台？它在这个平台上建了一层 ApplicationPaaS，全球所有标准化的功能全部放在同一个SaaS上，统一管理统一运维，每个地区在这个SaaS上有自己的营销内容，广告、用户券等等，整体的功能、流程全部标准化的SaaS当中。在这个上面，欧洲站、中国站和印度站，同时建立一个数据仓库，进来的数据只有交易数据和统一数据，用户数据和身份数据按照各国法案只能留在当地。这三个地方的数据如何存储？80%的标准化业务通过SaaS统一集中，20%通过定制化完成。
这一层用户的身份数据、行为数据都放在当地的数据中心，只有交易数据和用户数据的统计数据可以归集到数据仓库，提供的数据要在全球提供数据可修改、可删除的承诺和用户沟通机制，来解决各个地区数据法案的问题，这是一套全球化电商架构。
这是我今天想向各位展示的非常典型的利用云和容器化以及微服务来解决业务问题的典型场景，一个是金融，从封闭系统走向开放系统，一个是电商从地区化业务走向全球化业务，这是我今天分享的全部内容。
ThoughWorks是一家专门做IT服务的公司，既提供整体解决方案的设计，也提供相关能力的咨询，也提供相应基础设施的搭建和系统实施落地的工作，这一家端到端提供IT服务的公司，感谢大家。
提问1：你这个已经实施了吗？
曾学海：银行方面，已经有超过3家银行开始实施，只是实施范围有不同。电商也是两个范围，一个是纯线上，一个是不同的地方的线下。还有纯零售的没有放进去。
提问2：在第一个问题，金融那个案例里。我看到相当于说到400，这一套云的平台或者PaaS平台跟银行现有的，因为银行现在对很多新的业务有一个综合前置和外围的平台，这个云的平台跟那个前置的平台是什么定位？还是一个新的方式？
曾学海：现在这个前置平台在我们这个架构的影响下逐渐开始往微服务方式去做，以前的前置平台在不同的银行里也都跑在X86架构上，因为它不可能在核心系统上开发。它体现的问题是，这套系统并不是部署在云上，它也面临一个问题我是一个巨大的单体，我也希望从机房迁到云上，虽然都是X86架构，但云的弹性是不同的数量级，这时候同样要遵循系统要拆开、迁移、整合，这个需要一步一步去做，而不是各个系统全部搬上去，这个风险还是挺高的。
热门专题
