https://www.cnblogs.com/sammyliu/p/10425252.html

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

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

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

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

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

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

• 面向服务的架构—分布式的应用由可重用的服务组成
• 面向消息的架构—应用之间通过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

感谢您的阅读，欢迎关注我的微信公众号：