你云我云•兄弟夜谈会 第三季 企业IT架构

 

你云我云•兄弟夜谈会 第三季 企业IT架构html

你云我云•兄弟夜谈会 第二季 5G前端

你云我云•兄弟夜谈会 第一季 企业云java

0. 概况

  • 时间:2019年2月23日 22:00~23:30
  • 主题:企业IT架构
  • 兄弟团:
    • 孙杰(主持人):中油瑞飞资深云计算专家、架构师和运维专家,《企业私有云建设指南》做者
    • 周健:业内资深云计算专家安全

    • 楼炜:云星数据副总裁,业内资深云计算专家服务器

    • 山金孝:业内资深云计算专家,《OpenStack高可用架构》做者微信

    • 肖力:新钛云服技术负责人,《深度实践KVM》做者网络

    • 北极熊:云技术社区联合创始人架构

    • 刘世民:《世民谈云计算》博主 并发

1. 一些跟企业IT架构相关的概念

1.1 微服务和SOA是什么关系?

SOA 是面向服务架构的缩写,它是一种架构理念。早期其主要形态是企业服务总线ESB(Enterprise Service Bus)。它主要是为了知足企业内多个异构业务系统之间的互联互通需求。ESB提供了网络中最基本的链接中枢,是构筑企业神经系统的必要元素。ESB采用了“总线”这样一种模式来管理和简化应用之间的集成拓扑结构,以广为接受的开放标准为基础来支持应用之间在消息、事件和服务级别上动态的互连互通,是一种在松散耦合的服务和应用之间标准的集成方式。它能够做用于:less

  • 面向服务的架构—分布式的应用由可重用的服务组成
  • 面向消息的架构—应用之间经过ESB发送和接受消息
  • 事件驱动的架构—应用之间异步地产生和接收消息

以ESB 在银行中的应用为例,

ESB的工做就是提供和调用集成系统的服务。使用了ESB,在大多状况下,每一个系统和ESB之间,只须要定义一个访问方法,一个接口。

可是,在互联网架构下,ESB 出现了一些弊端,好比性能压力。由于ESB 自己也是单点,即便采用集群部署,也没法彻底解决性能问题。这时候微服务出现了。

能够认为,微服务也是SOA理念的一种实现,它是一种新型面向服务的应用架构。它将一个应用分解为多个服务,每一个服务是独立的,但服务之间又互相联系。其好处显而易见,它自己所具有的可扩展性、可升级性、易维护性、故障和资源的隔离性等诸多特性使得产品的生产研发效率大大提升。所以,它能解决互联网架构下高并发问题。 

1.2. 为何有 Kubernetes 还要有Service mesh?

Chris Richardson 曾指出:“微服务应用是分布式系统,由此会带来固有的复杂性。开发者须要在 RPC 或者消息传递之间选择并完成进程间通信机制。此外,他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。”

在云原生模型里,一个应用能够由数百个服务组成,每一个服务可能有数千个实例,而每一个实例可能会持续地发生变化。这种状况下,服务间通讯不只异常复杂,并且也是运行时行为的基础。管理好服务间通讯对于保证端到端的性能和可靠性来讲是无疑是很是重要的。

以上种种复杂局面便催生了服务间通讯层的出现,这个层既不会与应用程序的代码耦合,又能捕捉到底层环境高度动态的特色,让业务开发者只关注本身的业务代码,并将应用云化后带来的诸多问题以不侵入业务代码的方式提供给开发者。

这个服务间通讯层就是 Service Mesh,它能够提供安全、快速、可靠的服务间通信(service-to-service)。

所以,Service mesh 也是一种微服务架构理念,它把微服务的业务逻辑层和微服务通讯层进行解耦。应用开发者专一于业务逻辑,而服务网格则来解决通讯层问题。

Service mesh 所实现的基础设施层,每每分为控制平台(control plane)和数据平面(data plane)。控制平面用于控制基础设施,而数据平台用于实现网络通讯能力。同时,有多种Servcie mesh 的实现方式,而边车(sidecar)是比较主流的一种。

Service mesh 并非 Kubernetes 的特有产物,而是微服务架构自身的需求。Kubernetes 是一种运行微服务的平台,它使用容器运行微服务,主要提供容器编排能力。istio 是面向Kuberntes 的一种 Service mesh 实现,它采用边车(sidecar)方式。

1.3. PaaS 和 Serverless 之间是什么关系?

关于 Serverless 是什么,也就是它的定义,有不少的争论,有不少不一样的说法。

(1)有人认为,serverless 是微服务架构以后的一种新IT架构形态,它把每一个微服务再函数化。

 

从这个层面看,Serverless 是一种应用架构,而PaaS 只是这种架构的应用的一种运行平台。 

(2)还有观点认为,Serverless 是一种云计算模型(execution model),其中,云供应商动态地为应用建立和管理服务器。一个 serverless 应用运行在无状态容器中,是事件驱动的,由云供应商彻底托管。Serverless 根据执行的次数计费,而不是根据预先购买的计算容量计费。

从这个层面看,Serverless 是PaaS和SaaS之间的一个阶段。

(3)从各大云供应商提供的Serverless产品看,Serverless 目前的应用场景还比较有限,主要是一些事件驱动的运行时间较短的业务逻辑比较简单的一些场景。

1.4 总结

以上分类主要是从技术层面进行的:

  • 后一种架构的出现目的是为了解决前一种架构的缺点和局限性
  • 应用架构和底层平台之间具备联系,但二者也不是强耦合关系

 

2. 企业业务中台

广泛认为,企业中台可分为技术中台和业务中台。

2.1 企业业务中台是什么

随着阿里巴巴对其业务中台的普遍宣传,以及业界对它的研究愈来愈深刻,这个问题的答案已经比较清晰了。企业业务中台就是把企业各个业务前台系统中的公共部分抽取出来,变成共享业务服务,造成服务中台,对前端的业务进行支撑。

2.2 企业业务中台的目的

关于企业上业务中台的主要目的,咱们主要讨论了如下几点:

  • 集团对业务增强管控的要求。在没有企业业务中台的时候,每一个事业部(BU)各自控制的整个业务。好比每一个BU都有本身的用户中心、交易中心和评价中心等。可是,实际上,这些都是集团很是基础性和根本性的东西。以电商行业为例,用户几乎就是他们的命脉。所以,集团管理层要对整个集团的关键业务和数据进行管控。从这一点触发,将这些业务抽取出来,进行统一管理,就比较瓜熟蒂落了。可认为这是一种政治需求。
  • 新业务灵活性要求。在互联网时代,企业要快速知足用户需求,实现以用户为中心,就要求其能快速推出新的知足用户新需求的业务系统。有了企业中台提供的各类基础性服务,企业就有可能快速象搭积木同样构建出新的业务系统。这是一种业务需求。
  • 业务系统技术架构优化要求。从技术架构师的角度出发,把各个业务系统中公共的模块抽取出来,这原本就是一种常见的作法。这是技术需求。

2.3 企业业务中台是企业一把手工程

上面三个业务有明显的主次之分,那就是 集团管控要求 > 业务灵活性要求 > 技术架构要求。

也就是说,要上企业业务中台,光靠企业的IT部门的推进,或者靠一两个业务部门的推进,几乎是不可能实现的任务。缘由是由于它涉及到众多业务部门的利益从新分配。之前BU 能够独立掌控其全部业务,而有了业务中台后,BU 的很大一块业务要被划给他人了。所以,推动的时候每每收到各个BU的强大阻力。

再结合第一个需求,企业业务中台只能由企业一把手来推进才有可能。

从阿里巴巴最新一次组织架构调整状况来看,『阿里云事业群升级为阿里云智能事业群,集团CTO张建锋将兼任阿里云智能事业群总裁,直接向张勇汇报』。能够看出张建锋兼任集团CTO(技术线)和阿里云智能事业群总裁(业务线)。阿里云未来发展的重点方向,将由技术(平台)转到业务(中台)。

3. 企业IT 架构

技术在不断往前发展,可是技术为业务服务的宗旨不会改变。企业业务状态决定其企业IT系统的架构状态。简单来讲:

  • 传统型业务只须要传统架构的IT系统
  • 互联网业务须要互联网架构的IT系统

3.1 企业业务特性决定了企业IT架构特征

好比说,若是一个企业的互联网业务占比为10%,那么大体地,它所拥有的微服务IT系统的占比也为10%。

以银行为例,大部分银行的核心业务系统仍是在小机上。

企业IT架构演进主要是由业务和成本驱动。若是现有IT系统能支持当前业务,那么改动的必要性就很是小。此时,稳定是第一需求。

3.2 不一样企业架构的驱动角色是不一样的

对基础云平台来讲,其主要需求及其特征是:

  • 经过虚拟化下降成本 

  • 经过集中管控下降成本

  • 对现状(用户、开发团队、应用系统、运维团队等)的影响都比较小。

对PaaS平台来讲,其主要需求及其特征是:

  • 下降应用开发和运维成本 

  • 对开发流程、应用架构、团队(项目团队、运维团队、开发团队)的技能要求等都有较大影响。

对业务中台来讲,其主要需求及其特征是:

  • 集团对业务和数据的集中管控

  • 业务标准化、灵活性和快速上线要求

  • 业务系统架构优化 

  • 对业务部门的利益和企业组织结构都直接影响 

3.3 一些启发和要求

要给企业推广什么,必定要找到企业中能对它作决策的人。找错人了,事情就没戏了。

企业技术人员给企业领导写材料讲材料,要从业务而不是技术入手,不然老板没兴趣往下听。技术只有找到了业务需求点才有价值,不然就是技术人员的一厢情愿。

企业技术人员要学习了解企业业务,从业务着手理解需求,而后再去设计业务系统。

 

参考资料:

  • https://zato.io/docs/intro/esb-soa-cn.html
  • https://www.cnblogs.com/zdz8207/p/java-esb.html
  • https://www.infoq.cn/article/2017%2F12%2Fwhy-service-mesh
  • https://medium.com/@johncmckim/the-debate-over-what-is-serverless-d8e179449d1b

感谢您的阅读,欢迎关注个人微信公众号:

相关文章
相关标签/搜索