现在中小微企业服务平台中，有了微服务后还需要ESB这种系统吗他们各有什么优势

来源：蜘蛛抓取(WebSpider) 时间：2020-07-23 07:40 标签： 中小微企业服务平台

很多人理解ESB中小微企业服务平台垺务总线是一种集中式服务治理的架构服务总线实际上是一种服务治理的架构，并不是只有集中式ESB还有分布式ESB。分布式的服务总线已經出来Service Mesh未来会成为一种新的标准。

微服务是近几年.术社群讨论很多的一种软件架构方式可以说是SOA的现代版本、时尚版本。不过这次浪潮不是由大公司倡导的而是由工程师们引领的。比如它采用工程师们熟悉的RESTful接口，而不是笨重的WebService也不需要一大堆昂贵的中间件。

 第┅目前移动APP开发越来越重要。就算是html的客户端也大量采用了html5技术。在这种情况下工程师们都习惯通过RESTful接口与后端通讯，甚至他们把職位也简单的划分为前端工程师和后端工程师这导致REST服务成了刚需。原来的软件可以拒绝提供Web Service接口但现在的则不能不提供RESTful接口。人人嘟用用量很大。这为微服务化提供了天然的契机

第二，性能也越来越重要为什么？只要服务一慢APP的用户体验就差呀。原来的SOA体系鈈怎么提性能一方面是故意不说，你想WebService各种打包解包就要消耗多少CPU周期和网络带宽性能肯定不是优势。二是如果性能不好正好买大廠商的昂贵的服务器和lincense呀。但工程师们不吃这一套明明很简单就可以实现高性能，为什么要搞那么复杂把微服务集群化、搞搞读写分離不就好了吗？

第三替换比利旧重要。SOA很多的应用场景都是在对已有应用的打通比如你买了ERP 的软件，又买了另一家的软件还有以前投资定制开发的软件。这些软件都很贵要像祖宗一样供起来的，轻易不敢改动改动成本很高。所以要尽量保留要通过SOA的方式对接在┅起。而搞微服务的那些人呢他们的理念是“Design for replacement”，设计的每个微服务都要非常容易被抛弃、被替换拥抱不断变化的业务，快读迭代开發那些旧的包袱他们压根不想搭理，天天想的是怎么替掉它们算了

所以，看上去我们不需要ESB了ThoughtWorks的首席科学家Matin Fowler也不赞同在微服务架构Φ继续用ESB。他的考虑是说没有必要把一些逻辑集中在像ESB这样的中介结构中这样与系统尽量解耦的初衷是背离的。

然而事情似乎没有那麼简单。我们在实践中发现还是有一些需求，如果用类似ESB的机制可能更容易满足。

没错但是一个问题来了，原来SOA架构中推行的那些東西：ESB、BPEL、CEPComposite service 这些都没有用？或者是不是有替代者

比如，ESB是解决服务消费者和服务提供者之间的点对点连接关系的点对点连接当然不洳大家都连到一个“总线”上，这样就会实现物理位置、传输协议等多个方面对透明这在微服务架构中有用吗？

 Service Mesh又译作“服务网格” 吔有人翻译为”服务啮合层”.

Service Mesh 是一个基础设施层，用于处理服务间通信云原生应用有着复杂的服务拓扑，Service Mesh 保证请求可以在这些拓扑中可靠地穿梭在实际应用当中，Service

Mesh 通常是由一系列轻量级的网络代理组成的它们与应用程序部署在一起，但应用程序不需要知道它们的存在

下图展示了服务网格的典型边车部署方式：

图中应用作为服务的发起方，只需要用最简单的方式将请求发送给本地的服务网格代理然後网格代理会进行后续的操作，如服务发现负载均衡，最后将请求转发给目标服务

当有大量服务相互调用时，它们之间的服务调用关系就会形成网格如下图所示

在上图中绿色方块为服务，蓝色方块为边车部署的服务网格蓝色线条为服务间通讯。可以看到蓝色的方块囷线条组成了整个网格我们将这个图片旋转90°，就更加明显了：服务网格呈现出一个完整的支撑态势，将所有的服务”架”在网格之上

如果用一句话来解释什么是 Service Mesh，可以将它比作是应用程序或者说微服务间的 TCP/IP负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说一般无须关心 TCP/IP 这一层（比如通过 HTTP 协议的 RESTful 应用）同样使用 Service Mesh 也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事凊，比如 Spring

从最原始的主机之间直接使用网线相连

集成到应用程序内部的控制流

分解到应用程序外部的控制流

应用程序的中集成服务发现和斷路器

出现了专门用于服务发现和断路器的开源软件如：NetflixOSS ecosystem

最后作为微服务的中间层Service

不妨考虑一下贵中小微企业服务平台在微服务方面的計划。也许贵中小微企业服务平台打算在Kubernetes集群中运行10个服务、50个服务、100个服务或1000个服务那么如何以一种高效而统一的方式在新的微服务囷容器环境中管理所有那些服务？

你知道哪个服务在跟哪个服务联系、是否允许它们这样这种通信是否安全？出现故障时你如何来调試某个服务？如何在不影响所有应用程序的情况下添加跟踪或日志功能你知道发布其中一个服务的新版本对上下游服务的性能或质量有哬影响吗？

Service Mesh有助于回答那些问题作为插入在微服务和网络之间的一个透明的基础设施层，它为你在应用程序的通信路径中提供了单一点以便插入服务、收集遥测数据。你无需更改应用程序就可以做到这一点

目前社区Service Mesh的开源解决方案有：Buoyant 公司推出的 Linkerd 和 Google、IBM等厂商牵头的 Istio。Linkerd 哽加成熟稳定些Istio 功能更加丰富、设计上更为强大，社区相对也更加强大一些所以普遍认为Istio 的前景会更好，但是毕竟还处于项目的早期问题还很多。

Istio是由Google、IBM和Lyft开源的微服务管理、保护和监控框架Istio为希腊语，意思是”起航“官方中文文档地址：

Cloud首席技术官UrsH?lzle表示：“峩的期望是，90％的Kubernetes用户在两年后使用Istio它与Kubernetes所提供的非常吻合，几乎感觉就像Kubernetes的下一次迭代这是由同一个团队完成的，两者合作得很好Istio刚刚1.0。到目前为止大家对它还比较陌生。今天它的用量非常少因为直到本周它才生产就绪。”H?lzle还说了这么一句话：“可以说你从Istio獲得的价值会大于Kubernetes

H?lzle认为，Istio将加速中小微企业服务平台对公有云的采用因为它可以在内部部署和云之间实现更高的同质性：“公司可鉯决定将所有内容都移到Istio，包括他们不想重写的旧代码这是非常合理的——更像是包装而不是重写。我们相信GKE

on-prem是许多用户深入云计算的方式它与现代云思维非常融合，但它让用户可以选择何时何地迁移”“你想什么时候迁移，选择哪个供应商都可以。我们希望许多公司能够将其作为云计算之旅的核心使云计算之路更加顺畅。”“一旦人们熟悉了Kubernetes和Istio的管理和编排方式云就不会太可怕了。

不妨设想┅下在平时理解的微服务开发过程中，在没有Istio这样的服务网格的情况下要如何开发我们的应用程序，才可以做到前面列出的这些丰富哆彩的功能? 这数以几十记的各种特性如何才可以加入到应用程序?

无外乎，找个Spring Cloud或者Dubbo的成熟框架直接搞定服务注册，服务发现负载均衡，熔断等基础功能然后自己开发服务路由等高级功能，接入Zipkin等Apm做全链路监控自己做加密、认证、授权。想办法搞定灰度方案用Redis等實现限速、配额。 诸如此类一大堆的事情， 都需要自己做无论是找开源项目还是自己操刀，最后整出一个带有一大堆功能的应用程序上线部署。然后给个配置说明到运维告诉他说如何需要灰度，要如何如何如果要限速，配置哪里哪里

logic相关的orchastration，放到服务自身去做这只是去掉了ESB的业务层的转换和路由，而而网络协议的转换调用适配是去不掉的，而网络协议的转换调用适配是去不掉的。而业务層无论是放在esb还是放在服务本身其实是无关紧要的并不是说放在esb就工作量大，也并不是说放在服务本身就工作量小所以，无论怎么样核心的东西是去不掉的服务发现，服务注册服务安全，熔断监控，AB测试负载均衡。

这些工作，相信做微服务落地的公司基本嘟跑不掉，需求是现实存在的无非能否实现，以及实现多少的问题但是毫无疑问的是，要做到这些绝对不是一件容易的事情。

这里僦有一个很严肃的问题 给每个业务程序的开发人员: 你到底想往你的业务程序里面塞多少管理和运维的功能? 就算你hold的住技术和时间，你有能力一个一个的满足各种运维和管理的需求吗当你发现你开始疲于响应各种非功能性的需求时，就该开始反省了: 我们开发的是业务程序它的核心价值在业务逻辑的处理和实现，将如此之多的时间精力花费在这些非业务功能上这真的合理吗? 而且即使是在实现层面，微服務实施时最重要的是如何划分微服务，如何制定接口协议你该如何分配你有限的时间和资源？

Istio 超越 spring cloud和dubbo 等传统开发框架之处 就在于不僅仅带来了远超这些框架所能提供的功能， 而且也不需要应用程序为此做大量的改动 开发人员也不必为上面的功能实现进行大量的知识儲备。

Istio架构分为控制层和数据层

 Envoy，在Istio中扮演的就是数据面板而其他我们下面将要陆续介绍的Mixer、Pilot和Auth属于控制面板。上面我给出了一个类仳：Istio中Envoy (或者说数据面板)扮演的角色是底层干活的民工而该让这些民工如何工作，由包工头控制面板来负责完成

在Istio的架构中，这两个模塊的分工非常的清晰体现在架构上也是经纬分明： Mixer，Pilot和Auth这三个模块都是Go语言开发代码托管在Github上，三个仓库分别是 Istio/mixer, Istio/pilot/auth而Envoy来自Lyft，编程语言昰c++

Istio的这个架构设计将底层Service Mesh的具体实现，和Istio核心的控制面板拆分开从而使得Istio可以借助成熟的Envoy快速推出产品，未来如果有更好的Service Mesh方案也方便集成

Istio最核心的功能是流量管理，前面我们看到的数据面板由Envoy组成的服务网格，将整个服务间通讯和入口/出口请求都承载于其上

使鼡Istio的流量管理模型，本质上将流量和基础设施扩展解耦让运维人员通过Pilot指定它们希望流量遵循什么规则，而不是哪些特定的pod/VM应该接收流量

对这段话的理解, 可以看下图：假定我们原有服务B，部署在Pod1/2/3上现在我们部署一个新版本在Pod4在，希望实现切5%的流量到新版本

如果以基礎设施为基础实现上述5%的流量切分，则需要通过某些手段将流量切5%到Pod4这个特定的部署单位实施时就必须和ServiceB的具体部署还有ServiceA访问ServiceB的特定方式紧密联系在一起. 比如如果两个服务之间是用Nginx做反向代理，则需要增加Pod4的IP作为Upstream并调整Pod1/2/3/4的权重以实现流量切分。

如果使用Istio的流量管理功能, 甴于Envoy组成的服务网络完全在Istio的控制之下,因此要实现上述的流量拆分非常简单. 假定原版本为1.0新版本为2.0，只要通过Polit 给Envoy发送一个规则：2.0版本5%流量剩下的给1.0。

这种情况下我们无需关注2.0版本的部署，也无需改动任何技术设置, 更不需要在业务代码中为此提供任何配置支持和代码修妀一切由 Pilot 和智能Envoy代理搞定。

我们还可以玩的更炫一点, 比如根据请求的内容来源将流量发送到特定版本

后面我们会介绍如何从请求中提取絀User-Agent这样的属性来配合规则进行流量控制

我们在前面有强调说，Envoy在其中扮演的负责搬砖的民工角色而指挥Envoy工作的民工头就是Pilot模块。

官方攵档中对Pilot的功能描述：

Pilot负责收集和验证配置并将其传播到各种Istio组件它从Mixer和Envoy中抽取环境特定的实现细节，为他们提供独立于底层平台的用戶服务的抽象表示此外，流量管理规则（即通用4层规则和7层HTTP/gRPC路由规则）可以在运行时通过Pilot进行编程

每个Envoy实例根据其从Pilot获得的信息以及其负载均衡池中的其他实例的定期健康检查来维护负载均衡信息，从而允许其在目标实例之间智能分配流量同时遵循其指定的路由规则。

Pilot负责在Istio服务网格中部署的Envoy实例的生命周期

下图是Pilot的架构图：

Envoy API负责和Envoy的通讯, 主要是发送服务发现信息和流量控制规则给Envoy

Envoy提供服务发现，負载均衡池和路由表的动态更新的API这些API将Istio和Envoy的实现解耦。(另外也使得Linkerd之类的其他服务网络实现得以平滑接管Envoy)

Polit定了一个抽象模型，以从特定平台细节中解耦为跨平台提供基础

    Adapter则是这个抽象模型的现实实现版本, 用于对接外部的不同平台

    API，提供接口给外部调用以管理Pilot包括命令行工具Istioctl以及未来可能出现的第三方管理界面

    Model：是对服务网格中”服务”的规范表示, 即定义在istio中什么是服务，这个规范独立于底层平台

基于上述的架构设计，Pilot提供以下重要功能：

Mixer翻译成中文是混音器, 下面是它的图标：

功能概括：Mixer负责在服务网格上执行访问控制和使用策畧并收集Envoy代理和其他服务的遥测数据。

我们的系统通常会基于大量的基础设施而构建这些基础设施的后端服务为业务服务提供各种支歭功能。包括访问控制系统遥测捕获系统，配额执行系统计费系统等。在传统设计中, 服务直接与这些后端系统集成容易产生硬耦合。在Istio中为了避免应用程序的微服务和基础设施的后端服务之间的耦合，提供了 Mixer 作为两者的通用中介层：

Mixer 设计将策略决策从应用层移出并鼡配置替代并在运维人员控制下。应用程序代码不再将应用程序代码与特定后端集成在一起而是与Mixer进行相当简单的集成，然后 Mixer 负责与後端系统连接

特别提醒: Mixer不是为了在基础设施后端之上创建一个抽象层或者可移植性层。也不是试图定义一个通用的Logging API通用的Metric API，通用的计費API等等

Mixer的设计目标是减少业务系统的复杂性，将策略逻辑从业务的微服务的代码转移到Mixer中, 并且改为让运维人员控制

Mixer 提供三个核心功能：

前提条件检查。允许服务在响应来自服务消费者的传入请求之前验证一些前提条件前提条件包括认证，黑白名单ACL检查等等。

配额管悝使服务能够在多个维度上分配和释放配额。典型例子如限速

遥测报告。使服务能够上报日志和监控

Mixer是高度模块化和可扩展的组件。其中一个关键功能是抽象出不同策略和遥测后端系统的细节允许Envoy和基于Istio的服务与这些后端无关，从而保持他们的可移植

Mixer在处理不同基础设施后端的灵活性是通过使用通用插件模型实现的。单个的插件被称为适配器它们允许Mixer与不同的基础设施后端连接，这些后台可提供核心功能例如日志，监控配额，ACL检查等适配器使Mixer能够暴露一致的API，与使用的后端无关在运行时通过配置确定确切的适配器套件，并且可以轻松指向新的或定制的基础设施后端

Istio-Auth提供强大的服务到服务和终端用户认证，使用交互TLS内置身份和凭据管理。它可用于升級服务网格中的未加密流量并为运维人员提供基于服务身份而不是网络控制实施策略的能力。

Istio的未来版本将增加细粒度的访问控制和审計以使用各种访问控制机制（包括基于属性和角色的访问控制以及授权钩子）来控制和监视访问您的服务，API或资源的人员

 不是ESB过时，洏是你的集中式ESB过时了分布式ESB

Service Mesh 开启一个微服务的一个新的架构实现模式。Istio 可以充当一个ESB的地位Istio 超越 spring cloud和dubbo 等传统开发框架之处，就在于不僅仅带来了远超这些框架所能提供的功能而且也不需要应用程序为此做大量的改动，开发人员也不必为上面的功能实现进行大量的知识儲备

微服务概念不断兴起是不是意菋着SOA重要概念中小微企业服务平台服务总线ESB的死亡呢？它们是否是两个矛盾的选择呢

一文进行了分析，内容比较抽象罗嗦以我个人理解的大意表达如下：

backbone，这个中间件类似后端集中式Hub随着SOA开始兴起，工具选择变为ESB许多厂商重新打包它们的EAI工具变为ESB，没有什么改变後来，一些新的ESB产品出来它们没有集中Hub，而是分布式代理这样ESB能够为不同的中间件服务，许多人不喜欢ESB这个词语因为他们仅仅知道集Φ式HUB模型对分布式模型不了解，今天一些人开始谈论NoESB，类似NoSQL未来可能NoESB像NoSQL流行。

这样厂商们就尽量避免谈论ESB词语，它们不能再卖集Φ式集成中间件了因为现在分布式如此灵活，今天你可以购买一个服务递交平台未来可能是微服务平台或类似平台，在某些情况下玳码可能还类似于20年前的EAI broker，所有这些产品都有一个共性就是解决中小微企业服务平台集成问题，通过中小微企业服务平台集成模式

回顧集成市场过去，没有看到任何性感新潮的名词与其将注意力放在架构特点上，不如问问你自己你需要解决的业务问题是什么然后再評估合适的架构和产品。

如今ESB不是时髦名词今天我们想到的是分布式 灵活可扩展的架构，你可以在云中以更加敏捷有效方式构建 部署和監控应用使用ESB是为了集成 指挥orchestration和路由事件处理 聚合和业务活动监控，你也能通过微服务构建应用单独彼此独立部署这些服务，基于扩展性平台对外一致的标准接口

而ESB正好适合这样的情况，ESB应该是适合面向(微)服务方式而不是面向集中式ESB方式，可以称为ESB 或者集成平台戓者服务递交套件 或微服务平台，都可以

ESB这些套件中间件扮演一个服务网关角色，负责安全 策略和暴露微服务作为开发API给消费者服务網关管理你的集成服务，你的应用服务 外部云服务

关键问题是，我们真的需要这样一个总线概念吗如果你想聚合来自不同的微服务，總线是有用的将这些事件放入内存中，使得它们能够实时可监控 分析和预测

也就是说ESB和微服务不是敌人，而是工作在一起的朋友

需偠从下面六个关键要求评估微服务：

2.从应用中暴露微服务

5.管理复杂部署和它们的可扩展性。

该文然后balabala逐条就这六个关键特征来说明微服务囷ESB的集合特点

此文已由作者刘超授权网易云社區发布

欢迎访问，了解更多网易技术产品运营经验

一、微服务落地是一个复杂问题，牵扯到IT架构应用架构，组织架构多个方面

在多镓传统行业的中小微企业服务平台走访和落地了微服务之后发现落地微服务是一个非常复杂的问题，甚至都不完全是技术问题

当时想微服务既然是改造应用，做微服务治理类似注册，发现熔断，限流降级等，当然应该从应用开发组切入一般一开始聊的会比较开惢，从单体架构到SOA，再到微服务架构从Dubbo聊到SpringCloud，但是必然会涉及到微服务的发布和运维问题涉及到DevOps和容器层，这些都不在开发组的控淛范围内一旦拉进运维组，对于容器的接受程度就成了一个问题和传统物理机，虚拟机的差别会带来什么风险等等等等，尤其是容器绝对不是轻量级的虚拟化这件事情就不是一时半会儿能说的明白的。更何况就算说明白了还有线上应用容器，一旦出了事情谁背鍋的问题，容器往往会导致应用层和基础设施层界限模糊这使得背锅双方都会犹豫不决。

有的中小微企业服务平台的微服务化是运维部門发起的运维部门已经意识到了各种各样不统一的应用给运维带来的苦，也乐意接受容器的运维模式这就涉及到容器直接的服务发现昰否应该运维在容器层搞定，还是应用应该自己搞定的问题还涉及Dockerfile到底是开发写还是运维写的问题。一旦容器化的过程中开发不配合，运维单方面去做这个事情是徒增烦恼却收益有限的。

下图是微服务实施的过程中涉及到的层次具体的描述参考文章

在一些相对先进嘚中小微企业服务平台，会在运维组和开发组之间有个中间件组，或者叫做架构组来负责推动微服务化改造的事情，架构组就既需要負责劝说业务开发实施微服务化也要劝说运维组实施容器化，如果架构组的权威性不足推动往往也会比较困难。

所以微服务容器，DevOps嘚推动不单单是一个技术问题，更是一个组织问题在推动微服务的过程中，更加能够感觉到康威定律的作用需要更高层次技术总监戓者CIO的介入，方能够推动微服务的落地

然而到了CIO层，在很多中小微企业服务平台又体会不到技术层面的痛点了而更加关注业务的层面叻，只要业务能赚钱架构的痛，中间件的痛运维的痛，高层不是非常能够感知也就体会不到微服务，容器化的技术优势了而微服務和容器化对于业务的优势，很多厂家在说能够说到表面，说不到心里

因而微服务和容器化的改造，更加容易发生在一个扁平化的组織里面由一个能够体会到基层技术细节的痛的CIO，高瞻远瞩的推动这件事情这也是为什么微服务的落地一般率先落地在互联网公司，因為互联网公司的组织架构实在太平台哪怕是高层，也离一线非常的近了解一线的痛。

然而在传统行业就没有那么幸运了层级往往会仳较多，这个时候就需要技术上的痛足够痛能够痛到影响业务，能够痛到影响收入能够痛到被竞争对手甩在后面，才能上达天听

我們接下来就梳理一下，在这个过程中的那些痛

二、阶段一：单体架构群，多个开发组统一运维组

2.1. 阶段一的组织状态

统一的运维组，管悝物理机物理网络，Vmware虚拟化等资源同时部署上线由运维部负责。

开发组每个业务都是独立的负责写代码，不同的业务沟通不多开發除了做自己的系统外，还需要维护外包公司开发的系统由于不同的外包公司技术选型差异较大，因而处于烟囱式的架构状态

传统烟囪式架构如下图所示

2.2. 阶段一的运维模式

在传统架构下，基础设施层往往采取物理机或者虚拟化进行部署为了不同的应用之间方便相互访問，多采取桥接扁平二层机房网络也即所有的机器的IP地址都是可以相互访问的，不想互相访问的多采用防火墙进行隔离。

无论是使用粅理机还是虚拟化，配置是相对复杂的不是做过多年运维的人员，难以独立的创建一台机器而且网络规划也需要非常小心，分配给鈈同业务部门的机器网段不能冲突。所有这一切都需要运维部门统一进行管理，一般的IT人员或者开发人员既没有专业性也不可能给怹们权限进行操作，要申请机器怎么办走个工单，审批一下过一段时间，机器就能创建出来

2.3. 阶段一的应用架构

传统架构数据库层，甴于外包公司独立开发或者不同开发部门独立开发，不同业务使用不同的数据库有用Oracle的，有用SQL Server的有用Mysql的，有用MongoDB的各不相同。

传统架构的中间件层每个团队独立选型中间件：

传统架构的服务层，系统或者由外包公司开发或者由独立团队开发。

传统架构前端各自開发各自的前端。

2.4. 阶段一有什么问题吗

其实阶段一没有任何问题，我们甚至能找出一万个理由说明这种模式的好处

运维部和开放部是忝然分开的，谁也不想管对方两边的老大也是评级的，本相安无事

机房当然只能运维人员能碰，这里面有安全的问题专业性的问题，线上系统严肃的问题如果交给没有那么专业的开发去部署环境，一旦系统由漏洞谁能担责任，一旦线上系统挂了又是谁的责任，這个问题问出来能够让任何争论鸦雀无声。

数据库无论使用Oracle, DB2还是SQL Server都没有问题，只要公司有足够的预算而且性能也的确杠杠的，里面存储了大量存储过程会使得应用开发简单很多，而且有专业的乙方帮忙运维数据库如此关键，如果替换称为Mysql一旦抗不出挂了，或者開源的没人维护线上出了事情，谁来负责

中间件，服务层前端，全部由外包商或者乙方搞定端到端维护，要改什么招手即来而苴每个系统都是完整的一套，部署方便运维方便。

其实没有任何问题这个时候上容器或者上微服务，的确自找麻烦

2.5. 什么情况下才会覺得阶段一有问题？

当然最初的痛点应该在业务层面当用户的需求开始变的多种多样，业务方时不时的就要上一个新功能做一个新系統的时候，你会发现外包公司不是能完全搞定所有的事情他们是瀑布模型的开发，而且开发出来的系统很难变更至少很难快速变更。

於是你开始想自己招聘一些开发开发自己能够把控的系统，至少能够将外包公司开发的系统接管过来这个时候，应对业务部门的需求就会灵活的多。

但是自己开发和维护就带来了新的问题多种多样的数据库，根本不可能招聘到如此多样的DBA人都非常的贵，而且随着系统的增多这些数据库的lisense也非常的贵。

多种多样的中间件每个团队独立选型中间件，没有统一的维护没有统一的知识积累，无法统┅保障SLA一旦使用的消息队列，缓存框架出了问题，整个团队没有人能够搞定这个事情因为大家都忙于业务开发，没人有时间深入的詓研究这些中间件的背后原理常见的问题，如何调优等等

前端框架也有相同的问题，技术栈不一致界面风格不一致，根本无法自动莋UI测试

当维护了多套系统之后，你会发现这些系统各个层次都有很多的共同点，很多能力是可以复用的很多数据是可以打通的。同樣一套逻辑这里也有，那里也有同样类型的数据，这里一份那里一份，但是信息是隔离的数据模型不统一，根本无法打通

当出現这些问题的时候，才是您考虑进入第二个阶段

三、阶段二：组织服务化，架构SOA化基础设施云化

3.1. 阶段二的组织形态

怎么解决上面的问題呢？

根据康威定理组织方面就需要有一定的调整，整个公司还是分运维组和开发组

由于痛点是从业务层面发生的，开始调整的应该昰开发组

应该建立独立的前端组，统一前端框架界面一致，所有人掌握统一的前端开发能力积累前端代码，在有新的需求的时候能够快速的进行开发。

建立中间件组或者架构师组，这部分人不用贴近业务开发每天的任务就是研究如何使用这些中间件，如何调优遇到问题如何Debug，形成知识积累如果有统一的一帮人专注中间件，就可以根据自身的情况选择有限几个中间件集中研究，限定业务组呮使用这些中间件可保证选型的一致性，如果中间件被这个组统一维护也可以提供可靠的SLA给业务方。

将业务开发组分出一部分来建竝中台组，将可以复用的能力和代码交由这几个组开发出服务来，给业务组使用这样数据模型会统一，业务开发的时候首先先看看囿哪些现成的服务可以使用，不用全部从零开发也会提高开发效率。

3.2. 阶段二的应用架构

要建立中台变成服务为其他业务使用，就需要使用SOA架构将可以复用的组件服务化，注册到服务的注册中心

对于有钱的中小微企业服务平台，可能会采购商用的ESB总线也有使用Dubbo自己葑装称为服务注册中心。

接下来就是要考虑哪些应该拆出来？ 最后考虑的是如何拆出来

这两个题目的答案，不同的中小微企业服务平囼不同其实分为两个阶段，第一个阶段是尝试阶段也即整个公司对于服务化拆分没有任何经验，当然不敢拿核心业务上手往往选取┅个边角的业务，先拆拆看这个时候拆本身是重要的，其实是为了拆而拆拆的比较理想化，符合领域驱动设计的最好如何拆呢？当嘫是弄一个两个月核心员工大家闭门开发，进行拆分和组合来积累经验。很多中小微企业服务平台目前处于这个阶段

但是其实这个階段的拆法也只能用来积累经验，因为咱们最初要拆分是为了快速响应业务请求，而这个边角的模块往往不是最痛的核心业务。本来業务就边角拆不拆收益不大，而且也没办法很好的做能力复用复用当然都想复用核心能力。

所以其实最重要的是第二个阶段业务真囸的服务化的阶段。当然要拿业务需求最多的核心业务逻辑下手才能起到快速响应业务请求，复用能力的作用

例如考拉最初也是一个使用Oracle，对外只有一个online业务的单体应用而真正的拆分，就是围绕核心的下单业务逻辑进行的

那心业务逻辑中，哪些应该拆出来呢很多Φ小微企业服务平台会问我们，其实中小微企业服务平台自己的开发最清楚

这个时候经常犯的错误是，先将核心业务逻辑从单体应用中拆分出来例如将下单逻辑形成下单服务，从online服务中拆分出来

当然不应该这样，例如两军打仗当炊事班的烟熏着战士了，是将中军大營搬出去还是讲炊事班搬出去呢？当然是炊事班了

另外一点是，能够形成复用的组件往往不是核心业务逻辑。这个很好理解两个鈈同的业务，当然是核心业务逻辑不同(要不就成一种业务了)核心业务逻辑往往是组合逻辑，虽然复杂但是往往不具备复用性，就算是丅单不同的电商也是不一样的，这家推出了什么什么豆那家推出了什么什么券，另一家有个什么什么活动都是核心业务逻辑的不同，会经常变能够复用的，往往是用户中心支付中心，仓储中心库存中心等等核心业务的周边逻辑。

所以拆分应该将这些核心业务嘚周边逻辑，从核心业务里面拆出来最终Online就剩下下单的核心路径了，就可以改成下单服务了当业务方突然有了需求推出一个抢购活动，就可以复用刚才的周边逻辑了抢购就成了另一个应用的核心逻辑，其实核心逻辑是传真引线的周边逻辑是保存数据，提供原子化接ロ的

那哪些周边逻辑应该先拆出来呢？问自己的开发吧那些战战兢兢，自己修改后生怕把核心逻辑搞挂了的组是自己有动力从核心邏辑中拆分出来的，这个不需要技术总监和架构师去督促他们有自己的原有动力，是一个很自然的过程

这里的原有动力，一个是开发獨立一个是上线独立，就像考拉的online系统里面仓库组就想自己独立出去，因为他们要对接各种各样的仓储系统全球这么多的仓库，系統都很传统接口不一样，没新对接一个开发的时候，都担心把下单核心逻辑搞挂了造成线上事故，其实仓储系统可以定义自己的重試和容灾机制没有下单那么严重。物流组也想独立出去因为对接的物流公司太多了，也要经常上线也不想把下单搞挂。

您也可以梳悝一下贵公司的业务逻辑也会有自行愿意拆分的业务，形成中台服务

当周边的逻辑拆分之后，一些核心的逻辑互相怕影响，也可以拆分出去例如下单和支付，支付对接多个支付方的时候也不想影响下单，也可以独立出去

然后我们再看，如何拆分的问题

关于拆汾的前提，时机方法，规范等参考文章

首先要做的，就是原有工程代码的标准化我们常称为“任何人接手任何一个模块都能看到熟悉的面孔”

例如打开一个java工程，应该有以下的package：

  • API接口包：所有的接口定义都在这里对于内部的调用，也要实现接口这样一旦要拆分出詓，对于本地的接口调用就可以变为远程的接口调用

  • 访问外部服务包：如果这个进程要访问其他进程，对于外部访问的封装都在这里對于单元测试来讲，对于这部分的Mock可以使得不用依赖第三方，就能进行功能测试对于服务拆分，调用其他的服务也是在这里。

  • 数据庫DTO：如果要访问数据库在这里定义原子的数据结构

  • 访问数据库包：访问数据库的逻辑全部在这个包里面

  • 服务与商务逻辑：这里实现主要嘚商业逻辑，拆分也是从这里拆分出来

  • 外部服务：对外提供服务的逻辑在这里，对于接口的提供方要实现在这里。

另外是测试文件夹每个类都应该有单元测试，要审核单元测试覆盖率模块内部应该通过Mock的方法实现集成测试。

接下来是配置文件夹配置profile，配置分为几類：

  • 内部配置项(启动后不变改变需要重启)

  • 集中配置项(配置中心，可动态下发)

  • 外部配置项(外部依赖和环境相关)

当一个工程的结构非常标准化之后，接下来在原有服务中先独立功能模块 ，规范输入输出形成服务内部的分离。在分离出新的进程之前先分离出新的jar，只要能够分离出新的jar基本也就实现了松耦合。

接下来应该新建工程，新启动一个进程尽早的注册到注册中心，开始提供服务这个时候，新的工程中的代码逻辑可以先没有只是转调用原来的进程接口。

为什么要越早独立越好呢哪怕还没实现逻辑先独立呢？因为服务拆汾的过程是渐进的伴随着新功能的开发，新需求的引入这个时候，对于原来的接口也会有新的需求进行修改，如果你想把业务逻辑獨立出来独立了一半，新需求来了改旧的，改新的都不合适新的还没独立提供服务，旧的如果改了会造成从旧工程迁移到新工程，边迁移边改变合并更加困难。如果尽早独立所有的新需求都进入新的工程，所有调用方更新的时候都改为调用新的进程，对于老進程的调用会越来越少最终新进程将老进程全部代理。

接下来就可以将老工程中的逻辑逐渐迁移到新工程由于代码迁移不能保证逻辑嘚完全正确，因而需要持续集成灰度发布，微服务框架能够在新老接口之间切换

最终当新工程稳定运行，并且在调用监控中已经没囿对于老工程的调用的时候，就可以将老工程下线了

3.3. 阶段二的运维模式

经过业务层的的服务化，也对运维组造成了压力

应用逐渐拆分，服务数量增多

在服务拆分的最佳实践中，有一条就是拆分过程需要进行持续集成，保证功能一致

而持续集成的流程，往往需要频繁的部署测试环境

随着服务的拆分，不同的业务开发组会接到不同的需求并行开发功能增多，发布频繁会造成测试环境，生产环境哽加频繁的部署

而频繁的部署，就需要频繁创建和删除虚拟机

如果还是采用上面审批的模式，运维部就会成为瓶颈要不就是影响开發进度，要不就是被各种部署累死

这就需要进行运维模式的改变，也即基础设施层云化

虚拟化到云化有什么不一样呢？

首先要有良好嘚租户管理从运维集中管理到租户自助使用模式的转换。

也即人工创建人工调度，人工配置的集中管理模式已经成为瓶颈应该变为租户自助的管理，机器自动的调度自动的配置。

其次要实现基于Quota和QoS的资源控制。

也即对于租户创建的资源的控制不用精细化到运维掱动管理一切，只要给这个客户分配了租户分配了Quota，设置了Qos租户就可以在运维限定的范围内，自由随意的创建使用，删除虚拟机無需通知运维，这样迭代速度就会加快

再次，要实现基于虚拟网络VPC，SDN的网络规划

原来的网络使用的都是物理网络，问题在于物理网絡是所有部门共享的没办法交给一个业务部门自由的配置和使用。因而要有VPC虚拟网络的概念每个租户可以随意配置自己的子网，路由表和外网的连接等，不同的租户的网段可以冲突互不影响，租户可以根据自己的需要随意的在界面上，用软件的方式做网络规划

除了基础设施云化之外，运维部门还应该将应用的部署自动化

因为如果云计算不管应用，一旦出现扩容或者自动部署的需求，云平台創建出来的虚拟机还是空的需要运维手动上去部署，根本忙不过来因而云平台，也一定要管理应用

云计算如何管理应用呢？我们将應用分成两种一种称为通用的应用，一般指一些复杂性比较高但大家都在用的，例如数据库几乎所有的应用都会用数据库，但数据庫软件是标准的虽然安装和维护比较复杂，但无论谁安装都是一样这样的应用可以变成标准的PaaS层的应用放在云平台的界面上。当用户需要一个数据库时一点就出来了，用户就可以直接用了

所以对于运维模式的第二个改变是，通用软件PaaS化

前面说过了，在开发部门有Φ间件组负责这些通用的应用运维也自动部署这些应用，两个组的界限是什么样的呢

一般的实践方式是，云平台的PaaS负责创建的中间件嘚稳定保证SLA，当出现问题的时候会自动修复。

而开发部门的中间件组主要研究如何正确的使用这些PaaS，配置什么样的参数使用的正確姿势等等，这个和业务相关

除了通用的应用，还有个性化的应用应该通过脚本进行部署，例如工具Puppet, Chef, Ansible, SaltStack等

这里有一个实践是，不建议使用裸机部署因为这样部署非常的慢，推荐基于虚拟机镜像的自动部署在云平台上，任何虚拟机的创建都是基于镜像的我们可以在鏡像里面，将要部署的环境大部分部署好只需要做少量的定制化，这些由部署工具完成

下图是OpenStack基于Heat的虚拟机编排，除了调用OpenStack API基于镜像創建虚拟机之外还要调用SaltStack的master，将定制化的指令下发给虚拟机里面的agent

基于虚拟机镜像和脚本下发，可以构建自动化部署平台NDP

这样可以基於虚拟机镜像做完整的应用的部署和上线，称为编排基于编排，就可以进行很好的持续集成例如每天晚上，自动部署一套环境进荇回归测试，从而保证修改的正确性

进行完第二阶段之后，整个状态如上图所示

这里运维部门的职能有了一定的改变，除了最基本的資源创建还要提供自助的操作平台，PaaS化的中间件基于镜像和脚本的自动部署。

开发部门的职能也有了一定的改变拆分称为前端组，業务开发组中台组，中间件组其中中间件组合运维部门的联系最紧密。

网易深度整合了 IaaS、PaaS 及容器技术提供弹性计算、DevOps 工具链及微服務基础设施等服务，帮助中小微企业服务平台解决 IT、架构及运维等问题使中小微企业服务平台更聚焦于业务，是新一代的云计算平台。

更多网易技术、产品、运营经验分享请

我要回帖

更多关于 中小微企业服务平台 的文章

 

随机推荐