IBM邵萍：数字化重构传统企业IT架构

【IT168&ITPUB专稿】本文根据邵萍老师在2018年10月17日第十届中国系统架构师大会(SACC2018)现场演讲内容整理而成。

讲师简介：

邵萍，2003年加入IBM中国软件研发中心，先后担任工程师，开发经理及产品经理等职务，专注领域包括应用服务器、Java EE技术及云计算。

正文：

随着企业信息化的深入发展，云已成为诸多企业的核心战略。尤其是私有云，已占据企业重要位置。

根据Gartner以及IDC的数据显示，传统IT市场的增长率正在逐年下降，而以云IT和认知技术为代表的新兴市场，增长率则非常高。从IT形态来看，传统的IT架构正逐步被云架构、微服务模式取代。我们无需再去解释什么是云，很多客户都已经有了上云的规划，有的甚至已经有了长时间的云运营经验。所以，云一定是IT的未来。另外，云还会和一些新技术挂钩，包括认知计算、智能化解决方案等。只有这样，才能让技术引领业务创新。

云时代的IT架构变化

那么，云时代的IT架构有哪些变化?双态IT模式，是现阶段的典型特征。

经过几十年的发展，传统IT已经积累到一定的量级，我们不可能一下子全部抛掉，完全转入新的应用。如何在保护已有投资的前提下，重构过去的IT架构，向云端迁移?如何把认知计算、区块链、物联网等新技术纳入现有IT体系?如何通过技术发展，去推动企业业务的转型?如何通过小而美的微服务，通过云原生应用，以及DevOps流程，实现快速迭代?这些都是我们必须要考虑的新课题。

双态IT模式，即混合IT架构。以某银行客户为例，System of Records是企业的心脏，是最核心的业务架构，确保所有交易可靠、稳定和高效。但是，只做到这一步还不够，如何通过提升用户体验，通过更理想的交互形式，让业务更敏捷?我们要去构建企业的神经和大脑，让所有数据互联互通。

如今，很多银行都在做AI，通过认知计算技术，我们可以给客户画像，做智能的贷款分析等。这其实就是在构建企业大脑，通过技术手段去思考业务逻辑。

当然，企业要想实现敏态IT，实现数字化转型，只改变架构还不够，整个企业都要进行调整。以IBM软件开发转型的十年历程为例。2013年，IBM有 Product Manager产品经理职位;现在改为Offering Manager。为什么会有这样的变化?

以前产品的经理，看的是产品的生命周期，每个版本要做什么，如何向前推进。现在，只管产品还不够，产品要包含服务、实施以及市场等等内容，是一整套的解决方案。另外，就是软件的交付周期，由之前的3个月/半年/1年，转为现在每月/每周/每日，并且要有持续集成的能力。开发模式由最早的模敏开发捷式，转为现在的Design Thinking 设计思维。这种模式比敏捷方式更先进，会用户画像、头脑风暴等方式，去思考和设计我产品。并且，能快速发布，快速试错，快速跟进和演进。还有软件开发角色、技术能力的培养、组织结构以及员工绩效考核等，都发生了巨大的变化。

应用上云的策略与考量

那么，针对具体应用的云化，该从何处入手?

从很多客户的转型历程来看，其实上云过程基本经历了三个阶段：

第一阶段：1.0 Efficient Infrastructure基础架构平台。

第二阶段：2.0 Modern Applications。所有应用都在云上，有着非常成熟的PaaS平台的支持。但是，依然从IT视角考虑问题。

第三阶段：应该是从业务视角来考虑问题。即3.0 Re-imagined Processes阶段。要借助新技术手段重构以往的业务价值，比如：把认知能力纳入企业业务当中。此时，云平台已经具备足够的技术支撑能力，能打破企业边界，重构一个生态。

其实，企业上云的时候，会把所有应用进行分类。因为，并不是所有应用都适合上云。有些应用运行得很好，很稳定，目前企业也没新的业务需求，那就不必做什么更改，保持当前运行状态就好。一个企业大概会有20~30%这样的应用。对于这类现存应用，企业一般不做修改，重点是平台标准化与自动化，降本增效。另外，企业有70~80%的应用，需要继续往前走，需要借助现代化技术，实现迁移改造，利用新型平台与技术实现云化。 比如：迁移到容器云平台，对整个架构做一个微服务化的改造。最后，就是所有新应用，必须通过新技术、新架构去开发。

如何上云?

那么，传统Web应用到底如何上云?以IBM某大客户为例，这家企业基于IBM中间件上的传统开发，已经有十三、四年的历史了。应用体系庞大，整个架构更是盘根错节。他们希望继续通过IBM的技术去做一些改造，帮助他们上云。

这家企业原来的产品运行在传统的WEB服务器上，体量相对较大，有很多应用更适合通过云平台去解决一些问题。比如：负载均衡、资源池化、动态的拓展等等。但是，企业一旦上云，整个架构就要重新做切分。如何把传统的应用服务器做容器化的一个改造?这是企业发展的必然之旅!

首先，我们为什么要转向新型的应用服务器?企业进行了综合评估。由于架构庞大，当系统加入一些新的功能的时候，几个G的一个应用要经过长时间的测试，才能够稳定下来。因为，每次新加的代码，都有可能要替代之前的代码，代码演进效率很低。

其次，企业的应用要承载一些新型的、类似于互联网业务的压力。比如：双11，银行要在背后提供快捷支付功能，来保证双11交易。企业发现：双11的时候，尤其是12点钟一到，交易量开始呈爆发趋势，迅速上升。如何通过敏捷应用进行弹性管理?传统的中间件显然无法满足需求。

以2017年为例，这家银行的快捷交易峰值压力达到了1万笔，需要大规模的集群去支持峰值。传统应用服务器，很难快速扩展为几百个节点。并且峰值结束后，还要收缩回来。所以，IBM当时推荐了WebSphere Application Server新一代应用服务器，后来演化到Liberty。

在转型期间，这家企业对不同应用进行了试用，最终发现Liberty的好处。Liberty是一个企业级应用器，不管是从性能来讲，还是从支持力度来看，都比开源要好很多。对于传统服务器来说，Liberty无疑带来了颠覆式革命，等于把原来的架构全部打散、重写，是一个可热插拔的结构。

我们都知道，一个Web应用，用到的只是其中的几条，比如一个Servers的应用。但是如果我用传统服务器，可能我所有的功能都要记起来。但是Liberty不是。如果我是一个很简单的Web应用，我只需要支持它的功能集就可以了。一个简单的Web应用，包含我们的Web应用服务器，大概六七十兆就可以运行起来。它的安装包也很小，可以根据你的需求，再决定要不要去增加更多新模块支持。这样的业务场景和云平台天然适配，尤其是企业级业务平台，如何去支持这种小而美的快速迭代、快速伸缩需求?需要我们重新来审视。我们需要用云平台来管理整个应用的全生命周期，不再通过服务器本身去做这种负载均衡、弹性伸缩等等工作。

Kubernetes带来哪些价值?

上了容器化的一个新型的云服务器后，我们要考虑去用容器化的方式去部署应用。提到上云，我们首先想到的都是 IAAS层。但是，因为虚机技术有其特殊性：涉及Hypervisor，有Host os这一层，资源消耗非常高。容器更具轻量级的特点，不管是系统启动速度，系统资源消耗，还是性能、并发性等，都有更出色的表现，Liberty on Docker成为必然发展趋势。

容器是用来管理微服务，需要对之前的应用做一个更细粒度的拆分。之前，一个应用拆成20个、30个微服务很正常。每个微服务还要牵扯它自己的弹性伸缩，有的可能达到几百个几千个。这样的微服务如何去管理?一定要有一个容器编排平台，比如：Mesos、Swarm。其实，我们之前有很多技术选择，但是今年态势非常明朗，基本上就是Kubernetes，不管是从客户角度看，还是从友商角度看，Kubernetes都是一个主导性的技术方向。

Kubernetes能帮企业做什么呢?

首先，大量的容器怎么去管理?比如：我要发布一个应用，这个应用应该如何在上千个容器的资源中去放置?放在哪里?哪个是最合适的资源?放了之后如何去做负载均衡?一旦一个容器坏掉，不接受请求了，如何能够快速替换?以及我有一些应用发布，应该怎样进行回滚?还有，其他的服务治理的一些功能，应该如何处理?Kubernetes的技术发展得非常快，IBM推出了自己的基于容器的一个技术，基本上各大厂商都在推出自己相关的PaaS的容器云平台。

有了Kubernetes，如何去支持企业的生产环境?其实这是一个值得探讨的问题。因为毕竟Kubernetes是一个开源的架构，在生产环境里有很多企业级的运维需求。IBM容器云平台会去支撑这种异构硬件系统。但是我们发现，不是所有的客户都已经到了容器就绪的状态，它可能有一些传统的应用，会在虚机上运行很多时间，或者说不会只选择一家云厂商，可能还会有很多云厂商，以及其他的云平台。我们需要把它集成管理起来，所以我们还有一个多云管理组件，能把其他云代管进来。我们还做了很多企业级的增强，去帮助客户去在企业的环境里面去运行容器云。我们说的Pass级云平台，不仅仅只是中间件这层，还包括相关的服务。IBM把之前的传统配件去做容器化，放在云平台上，作为开箱即用的中间件服务，提供给客户。

在云端如何实现DevOps ?

另外，IBM在支持新型的云应用的时候，希望能够用DevOps的方式来做微服务应用的构建、发布、测试、上线、回滚等等这一系列流程，IBM会提供与DevOps相关的工具。

总体来说，其实企业级的生产环境需要很多额外的技术支撑能力。比如：日志能力。每一个容器都会产生自己的日志，当体量达到上千个节点的时候，这些日志如何去管理?如何快速检索、排查，生成意义的信息?这些都是关键点。还有监控，企业需要实时地看到所有容器当前的运行状况，是不是处于一个健康的状态，有没有出现什么问题?针对这些问题，IBM做了很多工作，铺设了更强大的企业级监控、运维工具。

再比如：计费计量问题。传统软件产品的买卖方式就是卖许可，买了就是永久性的。但是云平台计价模式不一样。我们可以按小时的方式去进行计费，通过计量功能区评估客户用了多少资源。

还有，容器云平台上会有大量的Image产生。有容器产生的，还有客户自己的、第三方的、有官方的等等。这些Image可能会有一些安全漏洞，所以IBM会提供一个Image扫描的工具，来保证你的Image在云端的安全性。

另外，很多传统客户用传统应用上云的时候，有很多挑战。首先，这个应用适不适合上云，上云的难度有多大，能不能根据现有应用给出一些建议?所以在IBM云平台上，能通过应用工具去扫描客户的应用。比如：传统的Web应用，我可以看到你现在所有的Code里面用到了哪些架构，我会告诉你，上云的技术匹配度是什么样，这里面有多少源代码能继续使用，哪些代码需要做一些更改。IBM云平台集成了大量的专家经验，帮客户去做代码的匹配，能给用户提供一些辅助的更改经验。并且生成一个评估报告，告诉你云迁移的难度是高、中、还是低，可能遇到的风险有哪些。

最重要的是，IBM有非常丰富的云端的Paas服务。安装了IBM的云平台之后，就会有几百个这样的一个云端服务，包括：Web应用服务器、数据库、消息中间件等等，都可以去在上面去进行安装，就是容器化模式。在云端，需要有更简单的模式帮助用户去安装部署自动化，尤其是自动化的安装部署，甚至回滚它的应用。IBM可以把几十个微服务组成一个应用，以微服务的方式来进行管理。

IBM还提供了多余管理功能，因为客户上云之旅不是一蹴而就的工程，需要一个中间段的过度，容器和虚拟化技术可以帮助客户走过共存阶段。IBM还提供了完整的DevOps开发运维一体化流水线工作的支持。

如何看待开源技术?

其实，IBM云平台底层很多技术都是开源的技术，不管是Docker，还是Kubernetes，甚至是多云管理，他要用一个开放的接口去集成第三方语言，都是一些开源的平台。所以很多技术实力很强的客户会问，为什么不能用开源的架构去打造自己的云平台?IBM的答案是：可以。但是开源架构有很多坑。

我们看到有几个大的客户，尤其是一些大的银行客户，他是用这种买服务的方式，请第三方的厂商来帮他去建立的Paas云。之后，由他自己去维护Paas云的生命周期。第一个坑是，这些客户不会长期关注开源社区，如果你要选一个第三方帮你去做的话，那一定需要第三方对这种开源社区有影响力，有一定的技术路线的掌控能力，保证你不会偏离这样一个技术路线。开源现在发展得非常快，几年前很火的框架，可能很快就不存在了。第二，如何才能有一个端到端的实施。因为上云，不像传统的卖软件，简单安装一下，把应用部署完，就可以了。在没有想清楚为啥要上云，如何上云这个问题之前，用户是不会付诸行动的。所以，上云是个复杂的过程。第三，开源的另外一大挑战是，集成开源中间件也有难度。因为，搭一个Paas云平台，不是一两种开源软件就能搭起来，有时候需要7、8个开源软件，甚至20多种开源技术。这些开源技术都有自己的社区，都以不同的步调在往前演进，如何在保证这些技术在演进之后还能跟得上?并且和其他的开源组件不冲突?需要不断去做测试。很多客户在两、三年之前自己去建Paas云，但是现在已经很难支撑了，因为更新换代是很麻烦的事情。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/31547898/viewspace-2219206/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/31547898/viewspace-2219206/