推广 热搜: 风动潜水泵  DXBL1536/127井下UPS电源  空气炮厂家  分销商城  BQG450/0.2气动隔膜泵  厂家直销  期货  万利期权  破拱助流装置  Bc支付接口 

博爱医院的新一轮改革轰轰烈烈的展开了电子元器件

   日期:2020-11-22     浏览:2    评论:0    
核心提示:  谢多人邀请,其实前面几位的回答已经差不多了,在这里仅谈下自己的简单总结。  ,原有的单个业务系统会拆分为多个可以独立

  谢多人邀请,其实前面几位的回答已经差不多了,在这里仅谈下自己的简单总结。

  ,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用。这些小应用之间通过服务完成交互和集成。每个小应用从前端web ui,到控制层,逻辑层,数据库访问,数据库都完全是独立的一套。在这里我们不用组件而用小应用这个词更加合适,每个小应用除了完成自身本身的业务功能外,重点就是还需要消费外部其它应用暴露的服务,同时自身也将自身的能力朝外部发布为服务。

  如果一句话来谈SOA和微服务的区别,即微服务不再强调传统SOA架构里面比较重的ESB企业服务总线,同时SOA的思想进入到单个业务系统内部实现真正的组件化。

  可以在“自己的程序”中运行,并通过“轻量级设备与HTTP型API进行沟通”

  。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构(在现有系统中分布一个API)区分开来。在服务公开中,许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能,那么就必须缩小进程范围。在微服务架构中,只需要在特定的某种服务中增加所需功能,而不影响整体进程。

  微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称,微服务是需要与业务能力相匹配,这种说法完全正确。不幸的是,仍然意味着,如果能力模型粒度的设计是错误的,那么,我们就必须付出很多代价。如果你阅读了Fowler的整篇文章,你会发现,其中的指导建议是非常实用的。在决定将所有组件组合到一起时,开发人员需要非常确信这些组件都会有所改变,并且规模也会发生变化。服务粒度越粗,就越难以符合规定原则。服务粒度越细,就越能够灵活地降低变化和负载所带来的影响。然而,利弊之间的权衡过程是非常复杂的,我们要在配置和资金模型的基础上考虑到基础设施的成本问题。

  首先对于应用本身暴露出来的服务,是和应用一起部署的,即服务本身并不单独部署,服务本身就是业务组件已有的接口能力发布和暴露出来的

  。了解到这点我们就看到一个关键,即我们在进行单个应用组件设计的时候,本身在组件内部就会有很大接口的设计和定义,那么这些接口我们可以根据和外部其它组件协同的需要将其发布为微服务,而如果不需要对外协同我们完全可以走内部API接口访问模式提高效率。

  其次,微服务架构本身来源于互联网的思路,因此组件对外发布的服务强调了采用HTTP Rest API的方式来进行

  。这个也可以看到在互联网开放能力服务平台基本都采用了Http API的方式进行服务的发布和管理。从这个角度来说,组件超外部暴露的能力才需要发布为微服务,其本身也是一种封装后的粗粒度服务。而不是将组件内部的所有业务规则和逻辑,组件本身的底层数据库CRUD操作全部朝外部发布。否则将极大的增加服务的梳理而难以进行整体服务管控和治理。

  微服务的基本思想在于考虑围绕着业务领域组件来创建应用,这些就应用可独立地进行开发、管理和加速。在分散的组件中使用微服务云架构和平台使部署、管理和服务功能交付变得更加简单。

  对于互联网谈到微服务架构一定会谈到Devops即开发测试和部署运维的一体化。当我们的单体应用以及拆分为多个小应用后,虽然整体架构可以松耦合和可扩展,但是如果拆分的组件越多,这些组件之间本身的集成和部署运维就越复杂。即任何一个组件,当他依赖的外部其它应用组件越多的时候,整个集成,部署和联调测试的过程就越复杂。这些如果完全靠我们手工去完成一是增加工作量,一是增加出错概率。

  原来谈组件化开发谈的最多的是单个组件的持续集成,包括配置环境集成,自动打包部署,自动化的冒烟测试等。对于微服务架构下首先仍然是要做好单个组件本身的持续集成,其次在这个基础上增加了多个组件的打包部署和组件间的集成。里面的核心思想就是Devops的思路,希望能够实现开发设计到部署运维的一体化。

  由于微服务架构里面强调了单个组件本身是可以在独立的进程里面运行,各个组件之间在部署的时候就能够做到进程级别的隔离。那么一台服务器我们可能需要初始化几十个甚至更多的进程来进行应用组件的部署。为了保持进程的隔离性,我们可以用虚拟机,但是当几十个进程都完全用独立的虚拟机就不现实的,而这个问题的解决刚好就是利用PaaS平台里面的轻量Docker容器来做这个事情,每个Docker是独立的容器刚好又完全做到进程级别的隔离,资源占用率又最小,这些特点刚好满足微服务架构的开发测试和自动化部署。

  前面这些问题思考清楚后就是考虑所有暴露的微服务是否需要一个统一的服务管控和治理平台,按照当前微服务架构的整体思路,虽然单个服务的实现和发布仍然是在组件内部完成的,但是这些组件暴露的服务本身的调用情况,服务本身的安全,日志和流量控制等

  由于微服务尽量都是通过HTTP API的方式暴露出去的,因此这种服务管理平台不需要像传统企业内部的ESB服务总线这么重。

  但是最基本的服务注册,服务代理,服务发布,服务简单的路由,安全访问和授权,服务调用消息和日志记录这些功能还是需要具备

  对于这种服务管控平台,核心需要讨论的就是服务每次调用本身的消息传递,输入和输出日志是否需要记录,当前就有两种做法,一种是不记录,管理平台只负责服务注册和目录发布,安全授权,实际的服务访问仍然是两个组件之间的点对点连接完成,这种方式下整个架构下获取更高的性能,同时服务管理平台也不容易成为大并发服务访问下的单点瓶颈;另外一种方式就是完全记录,在这种方式下就需要考虑服务管理平台本身的集群化不是,高并发下的性能问题。而个人建议最好的方式还是SOA服务管理平台应该提供两种管理能力,同时仅仅对核心的需要Log日志的服务进行日志记录,而其它服务只提供服务目录和访问控制即可。

  ===========2016.6.8日更新,增加Chris Richardson微服务系列读书笔记

  本文为阅读《Chris Richardson 微服务系列》的阅读笔记,具体原文参考:「Chris Richardson 微服务系列」服务发现的可行方案以及实践案例, 里面有另外四篇的链接,当前daocloud已经更新到第5篇事件驱动架构。

  文中强调的单体应用的场景,我在前面很多谈组件化和服务化的文章里面已经都谈到过了,即一个应用系统里面的模块没有办法做到彻底解耦,如果要实现按组件单独部署是不可能的,相互之间仍然有大量内部不可见依赖而导致了模块间无法拆分。

  变更或升级的影响分析困难,任何一个小修改都可能导致单体应用整体运行出现故障。

  无法拆分部署,出现性能瓶颈后往往只能够增加服务器或增加集群节点,但是DB问题难解决

  正是由于这些原因需要考虑引入微服务架构(实质仍然是单个应用本身的组件化和服务化),对于微服务文章里面有一个详细说明如下:

  一个微服务一般完成某个特定的功能,比如订单管理、客户管理等。每个微服务都是一个微型应用,有着自己六边形架构,包括商业逻辑和各种接口。有的微服务通过暴露 API 被别的微服务或者应用客户端所用;有的微服务则通过网页 UI 实现。在运行时,每个实例通常是一个云虚拟机或者 Docker 容器。

  从这个定义和说明仍然需要做一些关键理解,即在我前面谈微服务的文章里面谈到过的,即核心的几点包括了,

  其一足够构成一个独立小应用(从DB到UI),其二微服务应用之间只能通过Service API进行交互,其三一般运行在云虚拟机或更轻的Docker容器上。

  API Gateway,这实际上微服务架构里面的很重要的内容,其作用类似于传统企业内部的ESB服务总线,只是更加轻量和高性能来解决微服务的管控和治理问题。

  而对于负载均衡,缓存,路由,访问控制,服务代理,监控,日志等都属于基本的服务管控内容

  Scale Cube的3D模型,描述的相当好,即通过微服务架构实施后扩展性的变化。

  水平弹性扩展能力,即通过负载均衡来实现水平弹性扩展,但是DB问题无法解决,引入3

  当单个微服务应用引入了DB弹性扩展能力要解决的时候,我们引入了对数据库进行拆分和DaaS

  对于微服务架构的好处前面在讲单体应用的问题的时候已经谈到了,微服务架构正好是解决这些问题。而对于微服务架构的不足,简单总结如下:

  任何彻底的分解都将带来集成的复杂度,即模块在集成时候需要外部微服务模块更多的配合。

  稍大项目都涉及到上100个服务节点部署,还涉及到部署后的配置,扩展和监控问题。

  首先说下这篇文章的引入场景,以一个亚马逊购物网站的手机APP订单查看界面来举例,如果是一个单体应用,那么所有的界面需要获取信息都通过单体应用统一一个地址提供的多个Service API获取。但是转变为微服务架构后可以看到对于会员管理,商品管理,订单管理,财务结算管理等都已经拆分为了不同的微服务模块,需要从不同的服务提供地址调用不同的微服务模块提供的Service API来返回数据。

  在原文里面我们看到对于客户端和微服务模块间点对点直接通讯提了三个问题,如下:

  部分服务使用的协议对 web 并不友好,如二进制RPC或AMQP消息等。

  那么我们从传统的ESB能力来对上面三个问题进行一个说明,第一个问题即可能涉及到细粒度的API组合,类似组合服务无法做;其二是可能存在协议转换的问 题要解决;其三即服务透明的问题,即需要对客户端提供一个统一的服务目录以使底层服务透明。由于以上问题,引入了API服务网关的概念,再次强调,

  对于API服务网关即使微服务架构里面的轻量服务总线,解决服务管控和治理相关问题。

  API 网关是一个服务器,也可以说是进入系统的唯一节点。这与面向对象设计模式中的 Facade 模式很像。API 网关封装内部系统的架构,并且提供 API 给各个客户端。它还可能还具备授权、监控、负载均衡、缓存、请求分片和管理、静态响应处理等功能。

  API 网关负责服务请求路由、组合及协议转换。客户端的所有请求都首先经过 API 网关,然后由它将请求路由到合适的微服务。API 网关经常会通过调用多个微服务并合并结果来处理一个请求。它可以在 web 协议(如 HTTP 与 WebSocket)与内部使用的非 web 友好协议之间转换。

  API 网关还能为每个客户端提供一个定制的 API。通常,它会向移动客户端暴露一个粗粒度的 API。以产品详情的场景为例,API 网关可以提供一个端点(/productdetails?productid=xxx),使移动客户端可以通过一个请求获取所有的产品详情。API 网关通过调用各个服务(产品信息、推荐、评论等等)并合并结果来处理请求。

  对于API网关的优点,其实是类似传统ESB企业服务总线的优点,即实现服务透明,同时对于服务运行过程中的日志,安全,路由,缓存等问题进行统一配置和处理,而不需要每个微服务API实现时都去考虑。如开源的Dubbo服务总线即可以看作是一个API网关的实现。

  API网关和ESB的一些重要区别点在于API网关更加轻量和高性能,它不需要去考虑太多遗留系统和诸多协议的适配,其次也不需要考虑服务集成过程中的大 量数据转换和映射。同时为了提升服务网关的性能,一般API网关在实现过程中不会去记录详细的数据传输日志,或者类似Dubbo架构数据传输根本就不会通 过API网关。

  。客户端只需要同网关交互,而不必调用特定的服务。API 网关也有一些不足。它增加了一个我们必须开发、部署和维护的高可用组件。还有一个风险是,API 网关变成了开发瓶颈。

  简单来说,在我们期望的去中心化和全分布式架构中,网关又成了一个中心点或瓶颈点,正是由于这个原因我们在网关设计的时候必须考虑即使API Gateway宕机也不要影响到服务的调用和运行。

  对于大多数应用程序而言,API 网关的性能和可扩展性都非常重要。因此,

  将 API 网关构建在一个支持异步、I/O 非阻塞的平台上是合理的。有多种不同的技术可以实现一个可扩展的 API 网关

  。在 JVM 上,可以使用一种基于 NIO 的框架,比如 Netty、Vertx、Spring Reactor 或 JBoss Undertow 中的一种。一个非常流行的非 JVM 选项是 Node.js,它是一个基于 Chrome Javascript 引擎构建的平台。

  另一个方法是使用 NGINX Plus。NGINX Plus 提供了一个成熟的、可扩展的、高性能 web 服务器和一个易于部署的、可配置可编程的反向代理。NGINX Plus 可以管理身份验证、访问控制、负载均衡请求、缓存响应,并提供应用程序可感知的健康检查和监控。

  对于API网关需要实现底层多个细粒度的API组合的场景,文章推荐采用响应式编程模型进行而不是传统的异步回调方法组合代码。其原因除了采用回调方式导致的代码混乱外,还有就是对于API组合本身可能存在并行或先后调用,对于采用回调方式往往很难控制。

  基于微服务的应用程序是一个分布式系统,必须使用一种进程间通信机制。有两种类型的进程间通信机制可供选择。一种是使用异步的、基于消息传递的机制。有些实现使用诸如 JMS 或 AMQP 那样的消息代理,而其它的实现(如 Zeromq)则没有代理,服务间直接通信。另一种进程间通信类型是诸如 HTTP 或 Thrift 那样的同步机制。通常,一个系统会同时使用异步和同步两种类型。它甚至还可能使用同一类型的多种实现。总之,API 网关需要支持多种通信机制。

  注:如果服务是同步调用可以看到微服务模块之间本身是没有彻底解耦的,即如果A依赖B提供的API,如果B提供的服务不可用将直接影响到A不可用。除非同步服务调用在API网关层或客户端做了相应的缓存。因此为了彻底解耦,在微服务调用上更建议选择异步方式进行。

  对于大多数基于微服务的应用程序而言,实现 API 网关,将其作为系统的唯一入口很有必要。API 网关负责服务请求路由、组合及协议转换。它为每个应用程序客户端提供一个定制的 API。API 网关还可以通过返回缓存数据或默认数据屏蔽后端服务失败。

  基于微服务的分布式应用是运行在多台机器上的;一般来说,每个服务实例都是一个进程。因此,如下图所示,服务之间的交互必须通过进程间通信(IPC)来实现。

  对于分为这两个维度进行描述意义不太大,对于同步模式往往只能是1对1,而且还需要同步等待容易引起阻塞,而对于异步模块往往采用消息机制来实现,同时配合消息中间件可以进一步实现消息的发布订阅。

  而对于EDA事件驱动架构要看到其本质也是伊布消息中间件和消息的发布订阅。

  异步消息机制可以做到最大化的解耦,对于数据CUD的场景可以看到是比较容易通过异步消息机制实现的,但是会进一步引入事务一致性问题,即在采用异步消息 机制后往往通过base事务最终一致性来解决事务层面的问题。而对于查询功能可以看到是比较难通过异步消息API实现的,在引入这个之前可以看到需要考虑 两方面的问题并解决。

  其一是服务网关需要有数据缓存能力,以解决无法从源端获取数据的场景。其二是前端开发框架本身需要支持异步调用和数据装载模式,特别是对于数据查询功能对于用户来讲,在前端的感受仍然需要时同步的。即通过异步方式返回了查询数据后可以动态刷新前端展示界面。

  :这是不可避免要遇到的问题,特别是对于RestAPI调用,由于Json格式本身无Schema返回更加容易忽视了对服务 版本的管理和控制。要知道对于Json数据格式变化仍然会导致RestAPI调用后处理失败。因此服务版本仍然采用大小版本管理机制比较好,对于小版本变 更则直接对原有服务进行覆盖同时对所有受影响的服务消费端进行升级;而对于大版本升级则本质是新增加了一个新服务,而对于旧版本服务逐步迁移和替代。

  :文中提到了Netfilix的服务解决方案,对于失败问题的解决要注意常用的仍然是服务超时设置,断路器机制,流量控制,缓存数据或默认值返回等。不论采用哪种失败处理策略,都需要考虑应该尽量减少服务调用失败或超时对最终用户造成的影响。

  使用同步的、基于请求/响应的 IPC 机制的时候,客户端向服务端发送请求,服务端处理请求并返回响应。一些客户端会由于等待服务端响应而被阻塞,而另外一些客户端可能使用异步的、基于事件驱动的客户端代码,这些代码可能通过 Future 或者 Rx Observable 封装。然而,与使用消息机制不同,客户端需要响应及时返回。这个模式中有很多可选的协议,

  Thrift 也能够让你选择传输协议,包括原始 TCP 和 HTTP。原始 TCP 比 HTTP 更高效,然而 HTTP 对于防火墙、浏览器和使用者来说更友好。

  文中对于两种实现方式已经描述的相当详细,可以看到当前互联网OpenAPI平台和微服务架构实现中仍然是大量以采用Rest API接口为主。

  而对于消息格式的选择,可以看到在使用RestAPI接口的时候,更多的是采用了Json消息格式而非XML,对于SOAP WebService则更多采用了XML消息格式。如果采用Thrift则还可以采用二进制消息格式以提升性能。

  首先还是先说场景,看似简单的服务注册和服务目录库管理为何会变复杂,其主要的原因还是在结合了云端PaaS和Docker容器部署后,对于微服务模块部 署完成后提供出来的IP地址是动态在变化的,包括模块在进行动态集群扩展的时候也需要动态接入新的服务提供IP地址。正是由于这个原因引入了服务发现和管 理的困难度。

  在文章中提到了两种服务发现模式,即客户端发现模式和服务端发现模式,分开描述如下:

  使用客户端发现模式时,客户端决定相应服务实例的网络位置,并且对请求实现负载均衡。客户端查询服务注册表,后者是一个可用服务实例的数据库;然后使用负 载均衡算法从中选择一个实例,并发出请求。客户端从服务注册服务中查询,其中是所有可用服务实例的库。客户端使用负载均衡算法从多个服务实例中选择出一 个,然后发出请求。

  注:这是类似Dubbo实现机制一样的两阶段模式,即任何一个服务的消费都需要分两个步骤进行,

  第一步首先是访问服务注册库(更多是API GateWay提供的一个能力)返回一个已经动态均衡后的服务可用地址,第二步即客户端和该地址直接建立连接进行服务消费和访问。

  在这种模式的实现中有两个重点,其一是动态负载均衡算法,其二是服务网关需要能够对原始服务提供点进行实时的心跳检测以确定服务提供的可用性。

  Netflix OSS 是客户端发现模式的绝佳范例。Netflix Eureka 是一个服务注册表,为服务实例注册管理和查询可用实例提供了 REST API 接口。Netflix Ribbon 是 IPC 客户端,与 Eureka 一起实现对请求的负载均衡。

  缺点:底层的IP虽然动态提供出去了,但是最终仍然暴露给了服务消费方,再需要进一步做安全和防火墙隔离的场景下显然是不能满足要求的。

  客户端通过负载均衡器向某个服务提出请求,负载均衡器查询服务注册表,并将请求转发到可用的服务实例。如同客户端发现,服务实例在服务注册表中注册或注销。在原文中有图示,基本看图就清楚了,即在服务注册库前新增加了一个Load Balancer节点。

  服务端发现模式兼具优缺点。它最大的优点是客户端无需关注发现的细节,只需要简单地向负载均衡器发送请求,这减少了编程语言框架需要完成的发现逻辑。并且 如上文所述,某些部署环境免费提供这一功能。这种模式也有缺点。除非负载均衡器由部署环境提供,否则会成为一个需要配置和管理的高可用系统组件。

  服务注册表需要高可用而且随时更新。客户端能够缓存从服务注册表中获取的网络地址,然而,这些信息最终会过时,客户端也就无法发现服务实例。因此,服务注册表会包含若干服务端,使用复制协议保持一致性。

  首先可以看到服务注册表本身不能是单点,否则存在单点故障,当服务注册表有多台服务器的时候同时需要考虑服务注册库信息在多台机器上的实时同步和一致。我们操作和配置服务注册信息的时候往往只会在一个统一的服务管控端完成。

  其次如果服务注册服务器宕机是否一定影响到服务本身的消费和调用,如果考虑更高的整体架构可用性,还可以设计对于服务注册库信息在客户端本地进行缓存,当服务注册表无法访问的时候可以临时读取本地缓存的服务注册库信息并发起服务访问请求。

  对于服务注册表,文章提供了三种选择,感觉最常用的实现仍然是基于ZooKeeper进行的。

  如前所述,服务实例必须在注册表中注册和注销。注册和注销有两种不同的方法。方法一是服务实例自己注册,也叫

  (self-registration pattern);另一种是采用管理服务实例注册的其它系统组件,即

  虽然方法一把服务实例和服务注册表耦合,必须在每个编程语言和框架内实现注册代码。但是在自己实现完整微服务架构中,考虑到PaaS平台下微服务模块的动 态部署和扩展,采用方法1相当来说更加容易实现。但是方法1仍然不能代替服务注册库本身应该具备的服务节点的心跳检测能力。

  首先,可以肯定的是SOA和微服务的确是一脉相承的,大神Martin Fowler提出来这一概念可以说把SOA的理念继续升华,精进了一步。其核心思想是在应用开发领域,使用一系列微小服务来实现单个应用的方式途径,或者说

  ,可以是使用不同的编程语言编写。而SOA可能包含的意义更泛一些,更不准确一些。

  其次,从实现方式上,两者都是中立性,语言无关,协议跨平台,相比SOA,微服务框架将能够带来更大的敏捷性,并为你构建应用提供更轻量级、更高效率的开发。而SOA更适合大型企业中的业务过程编排、应用集成。另外还有

  ,甚至是每个操作(或方法)都是独立开发的服务,足够小到不能再进行拆分。而SOA没有这么极致的要求,只需要接口契约的规范化,内部实现可以更粗粒度,微服务更多为了

  最后,从部署方式上,这个是最大的不同,对比Monolithic(有人翻译为单体)的Java EE部署架构,通过展现层打包WARs,业务层划分到JARs最后部署为EAR一个大包,而微服务则打开了这个黑盒子,

  把应用拆分成为一个一个的单个服务,应用Docker技术,不依赖任何服务器和数据模型,是一个 全栈应用,可以通过自动化方式独立部署,

  ,通过轻量的通讯机制联系,经常是基于HTTP资源API,这些服务基于业务能力构建,能实现集中化管理(因为服务太多啦,不集中管理就无法DevOps啦)。

  很久以前的一天,Martin 在跟好友的交流中悟到了一种很棒的架构设计。他总结了一下,然后告诉了好友,好友说,这不是新鲜东西,早有人总结了,叫做 SOA。

  Martin 很高兴,开始在公司内外推广 SOA。结果,不停有人质疑和挑战他。

  你这不是 SOA 吧?SOA 这里应该是如此这般的。对,这里我对 SOA 的理解是这样的。你看,这本 SOA 的书说的和你说的有出入。粒度?SOA 没有谈到这个呀,你这不是 SOA。分层跟 SOA 没有关系,你为什么要说这个呢?…

  Martin 没办法,心一横,老子就叫它 Martins SOA。老子发明的词,老子就是最高权威,有最终解释权。还有谁不服?

  同事们一看,这思想本身很不错,值得推广,但叫 Martins SOA 太没品了吧?还是要取个好一点的名字,最好还能跟 SOA 有某种暗示传承。干脆就叫 Microservices 好了,又新,又有服务含在其中。

  Martin 忿忿地接受了这个建议,心里想着:妈的,明明就是 SOA,一群傻逼非要逼我取个新名字。

  后来 Martin 发现每次提一个东西就会收到旧恶傻势力对解释权的挑战,所以每次要提一个什么概念,都去发明一个新词,免得一群人在那一边质疑挑战,一边大谈“我的理解”。

  一个名词产生之后,命名者的解释权就会随着时间而弱化(比如 Cooper 发明的 Persona 就被无数设计师乱用)。敏捷已经有点烂了,等微服务也烂了,我们还会发明新词。

  线年,又是一个春天,莆田乡下的赤脚医生吴大牛被改革的春风吹的心潮澎湃,说干就干,吴大牛趁着夜色朦胧找大队支书汇报了汇报思想,第二天就承包了村卫生室,开启了自己的在医疗圈的传奇历程。

  乡村诊所大家都知道,没什么复杂的东东,房子只有一间,一个大柜台中间隔开,一半是诊疗兼候诊区,一半是药房,看病就直接找医生,如果前面有人就自己找个位子坐下,排队等一会,秩序倒也井然,看完病了医生直接给抓药,然后下一个继续,也不需要护士和药剂师,吴大牛一个人全部包办。

  辛辛苦苦忙碌了十年,时间来到了八九年,又是一个春天,昔日的单身汉吴大牛已成为十里八乡的知名人物,媳妇娶上了不说,家里还增加了一对双胞胎儿子,二层的小洋房也甚是气派。可是也有烦心事,尽管乡村诊所扩大到了两间,媳妇还偶尔能去帮帮忙,但是医生还是只有自己一个,天天从早忙到晚挣的都是一份钱,想多挣点怎么办?吴大牛日思夜想,还真给他想出来一招,怎么办,扩大规模,多招几个医生一起干。原来吴大牛只能治头疼脑热和跌打损伤,现在新招了一个医科大学的毕业生刘小明专治感冒发烧,又从邻村请来了老大夫李阿花专治妇科病,现在一个普通的小诊所就变成了有三个独立科室加一个公共药房(吴大牛媳妇负责)的小医院了,吴大牛是外科主任兼院长,收入那可比之前翻了三番。人逢喜事精神爽,大牛院长请县里的书法名家为新医院书写了牌匾--“博爱医院”,挑了一个黄道吉日正式挂了上去。

  一晃十年过去了,又是一个春天,吴大牛的博爱医院已经发展到了内科外科妇科五官科骨科生殖科六个科室,每个科室3到5名医生不等,也耗费巨资购进了血夜化验B超等先进仪器,大牛院长也早已脱离了医疗一线,成为了专职的管理者,但是医院的大事小事大家都找他,就这三十多号员工搞的他每天是焦头烂额,想再扩大规模实在是有心无力了。要说还是大学生有水平,老部下刘小明给大牛院长献了一计,把各个科室独立出去,让各个科室主任自己管理,大牛院长只管科室之间的协调和医院发展的大事,这样既能调动基层的积极性,又能把大牛院长解放出来扩大生产抓大事谋大事,岂不妙哉?就这样,博爱医院的新一轮改革轰轰烈烈的展开了。

  又是一个十年,又是一个春天,大牛院长已成为本地知名的企业家,博爱医院也发展到了二十三个科室数百名员工,发展中也出现了新问题,由于各个科室独立挂号、收费、化验,有的科室整天忙忙碌碌效益好,有的科室就相对平庸些,连分到的各种检查仪器都不能满负荷运行,整个医院养了不少闲人。这时候大牛院长视野也开阔了,请来了管理专家进行了顶层设计,把原来分散到各个科室的非核心服务全部收归集中管理,把原来二十三个挂号窗口整合为十个,二十三个收费窗口整合为八个,集中布设在一楼大厅为全院服务,还把分散在各个科室的检查仪器集中起来成立独立的检验科,也为全院服务,这样人人有活干,整个医院的服务能力又上了一个新台阶,这轮改革后博爱医院通过了各级部门的鉴定成为了远近驰名的三甲医院,吴大牛也换身一变成为了博爱集团的CEO兼董事长,下一步就准备IPO上市了。

  说到这里大家可能有点糊涂,这个跟微服务有嘛关系?在孙老师看来,大牛诊所的1.0阶段就相当于软件开发的单体结构,一个程序员打天下,从头编到尾,很难做大做强。大牛诊所的2.0阶段就相当于软件开发的垂直结构,各科室按照业务划分,很容易横向扩展。博爱医院的1.0阶段就相当于软件开发的SOA结构,除了药房(数据库)外各个服务独立提供(科室主任负责),但需要大牛院长(ESB总线阶段就相当于软件开发的微服务结构,公共服务院内共享,科室主任管理功能弱化(只管医生业务),优点是扩容方便,哪个部门缺人直接加,不用看上下游,资源利用率高,人员和设备效率高。

  SOA的提出是在企业计算领域,就是要将紧耦合的系统,划分为面向业务的,粗粒度,松耦合,无状态的服务。服务发布出来供其他服务调用,一组互相依赖的服务就构成了SOA架构下的系统。

  基于这些基础的服务,可以将业务过程用类似BPEL流程的方式编排起来,而BPEL反映的是业务处理的过程,这些过程对于业务人员更为直观,调整也比hardcode的代码更容易。

  我们知道企业计算领域,如果不是交易系统的话,并发量都不是很大的,所以大多数情况下,一台服务器就容纳将许许多多的服务,这些服务采用统一的基础设施,可能都运行在一个应用服务器的进程中。虽然说是面向服务了,但还是单一的系统。

  而微服务架构大体是从互联网企业兴起的,由于大规模用户,对分布式系统的要求很高,如果像企业计算那样的系统,伸缩就需要多个容纳续续多多的服务的系统实例,前面通过负载均衡使得多个系统成为一个集群。

  但这是很不方便的,互联网企业迭代的周期很短,一周可能发布一个版本,甚至可能每天一个版本,而不同的子系统的发布周期是不一样的。

  而且,不同的子系统也不像原来企业计算那样采用集中式的存储,使用昂贵的Oracle存储整个系统的数据,二是使用MongoDB,Hbase,Cassandra等NOSQL数据库和Redis,memcache等分布式缓存。

  那么就倾向采用以子系统为分割,不同的子系统采用自己的架构,那么各个服务运行自己的Web容器中,当需要增加计算能力的时候,只需要增加这个子系统或服务的实例就好了,当升级的时候,可以不影响别的子系统。这种组织方式大体上就被称作微服务架构。

  微服务与SOA相比,更强调分布式系统的特性,比如横向伸缩性,服务发现,负载均衡,故障转移,高可用。互联网开发对服务治理提出了更多的要求,比如多版本,比如灰度升级,比如服务降级,比如分布式跟踪,这些都是在SOA实践中重视不够的。

  Docker容器技术的出现,为微服务提供了更便利的条件,比如更小的部署单元,每个服务可以通过类似Node.js或Spring Boot的技术跑在自己的进程中。可能在几十台计算机中运行成千上万个Docker容器,每个容器都运行着服务的一个实例。随时可以增加某个服务的实例数,或者某个实例崩溃后,在其他的计算机上再创建该服务的新的实例。

  很多人说微服务是 SOA 的延续,都强调松耦合,只是 SOA 高度依赖服务总线(ESB),而微服务不需要。

  其实,Martin Fowler 本人虽然说了微服务的很多参考原则,但并没有明确提出微服务架构的最佳实践。我们反过来理解,SOA 和微服务架构这两个概念成型的年代不一样,实践的主体、要解决的问题也是不一样的,同时从结果来看,SOA 并没有那么成功,而微服务架构在当前的互联网业务研发中发挥着巨大的价值。

  SOA 的探索大概始于 2000 年(概念产生可能更早一些),大家知道当初 ERP、CRM、OA 之类的信息系统都是一套套部署起来的,不同系统往往由不同的供应商分别开发的,技术差别也很大,各个系统孤零零的,企业于是有了应用集成和数据集成的需求,SOA 就出来了,各个系统对外提供粗粒度的服务供外部系统访问,所有的服务都集中在一个 ESB 上,曾经 SOA 和 SOA 治理是信息化领域的热门话题,然而这种集成方式开发代价大、通信效率低,且有单点故障的风险, 实际上在企业中并没有得到大规模应用。

  微服务架构则是在互联网相当成熟的时代,互联网业务规模增长快,变更多且频繁,互联网技术团队强烈关注 DevOps 和持续交付这样的研发理念,传统的单体架构无法满足迭代速度、系统扩展性、资源利用率优化等需求,微服务架构就闪亮登场了,通过解耦,解决掉各种难题。亚马逊、Netflix 和 Facebook 等主要的互联网公司,就是微服务架构实践的先驱,他们取得了很好的效果,也产生了一系列的最佳实践。

  容器技术流行之后,国内采用微服务架构的企业越来越多了。现在不仅是互联网公司,很多传统企业,比如德邦快递,都已经采用微服务架构来实现高效研发以提升公司竞争力了。

  所以说,从某种程度上,我们可以认为,SOA 和微服务是差异非常大的两种体系,差别不仅仅在于服务通信模式,更在于对扩展性、容错性、DevOps的支持。

  前面提到容器,容器并不是很新技术,但 SOA 并不喜欢使用容器,而 Docker 和微服务的关系就比较紧密了。微服务的成功,不仅在于架构的先进性能够匹配当前的业务痛点,更在于开源微服务框架之外,容器云等等配套的工具链也已经成熟。“微服务”带一个微字,不同于 SOA 往往是一个完整的子系统,这更复合 UNIX 设计的哲学(每种服务只做一件事情),但这意味着引入太多的复杂性,比如服务调用有问题怎么排查,但容器编排、APM、CI/CD(持续集成/持续交付)、自动化测试等功能的配合,完美解决了各种问题。我们看各家的微服务实践,往往都是 Kubernetes 容器平台、微服务治理框架和 DevOps 系统一起上的。

  所以,网易云轻舟微服务的设计,也是着眼于微服务应用生命周期的需求,提供了微服务框架、API网关、容器服务、DevOps、AIOps 和全自动化测试等模块。

  潜水知乎多年,今天把我知道的说出来,希望高手多多提意见。。。。。。。。。。。。。。。。

  这半年的实习,接触了分布式集群处理和自动化运维监控,我已从传统的单机处理的理念转变到分布式处理,我们处理了很多实际的问题,发现虽然分布式非常吃硬件,但是运行的效率和时间却是大大的缩减了,例如我们分析处理无锡市九个卡口一年的交通数据,这个数据量大家估计都是懂得,对这些数据的处理仅仅就用了两天!因此我当时坚定不移的确定,以后的程序处理和业务的处理必然是往大集群、分布式方向发展的!扯了这么多没用的,关于微服务这个,也是这几天刚刚开始接触(老大出差一回来跟我们说的)。

  微服务:采用一组服务的方式来构建一个应用,服务独立部署在不同的进程中,不同服务通过一些轻量级交互机制来通信,例如 RPC、HTTP 等,服务可独立扩展伸缩,每个服务定义了明确的边界,不同的服务甚至可以采用不同的编程语言来实现,由独立的团队来维护。简单的来说,一个系统的不同模块转变成不同的服务!而且服务可以使用不同的技术加以实现!

  SOA我想我就不用细说了,使用java EE开发过的都知道其中的具体流程和步骤,J2EE的确在统一开发中有着很好的使用,但是随着模块功能的不断扩展或者变动,对于其中一点的维护可能会影响到整体的项目。

  所以有了微服务,彻底的将耦合性再次的降低了。为什么要讲我实习呢,因为微服务的使用会随着单一进程的传统应用被拆分为一系列的多进程服务后,意味着开发、调试、测试、集成、监控和发布的复杂度都会相应增大。 必须要有合适的自动化基础设施来支持微服务架构模式,否则开发、运维成本将大大增加。所以自动化运维是十分必要的。

  原文链接:多研究些架构,少谈些框架(1) -- 论微服务架构的核心概念

  微服务现在辣么火,业界流行的对比的却都是所谓的Monolithic单体应用,而大量的系统在十几年前都是已经是分布式系统了,那么微服务作为新的理念和原来的分布式系统,或者说SOA(面向服务架构)是什么区别呢?我们先看相同点:

  需要考虑分布式下面的事务一致性,CAP原则下,两段式提交不能保证性能,事务补偿机制需要考虑;

  同步调用还是异步消息传递,如何保证消息可靠性?SOA由ESB来集成所有的消息;

  都需要统一的Gateway来汇聚、编排接口,实现统一认证机制,对外提供APP使用的RESTful接口;

  同样的要关注如何再分布式下定位系统问题,如何做日志跟踪,就像我们电信领域做了十几年的信令跟踪的功能;

  是持续集成、持续部署?对于CI、CD(持续集成、持续部署),这本身和敏捷、DevOps是交织在一起的,我认为这更倾向于软件工程的领域而不是微服务技术本身;

  使用不同的通讯协议是不是区别?微服务的标杆通讯协议是RESTful,而传统的SOA一般是SOAP,不过目前来说采用轻量级的RPC框架Dubbo、Thrift、gRPC非常多,在Spring Cloud中也有Feign框架将标准RESTful转为代码的API这种仿RPC的行为,这些通讯协议不应该是区分微服务架构和SOA的核心差别;

  是流行的基于容器框架还是虚拟机为主?Docker和虚拟机还是物理机都是架构实现的一种方式,不是核心区别;

  服务的切分上有比较大的区别,SOA原本是以一种“集成”技术出现的,很多技术方案是将原有企业内部服务封装为一个独立进程,这样新的业务开发就可重用这些服务,这些服务很可能是类似供应链、CRM这样的非常大的颗粒;而微服务这个“微”,就说明了他在切分上有讲究,不妥协。无数的案例证明,如果你的切分是错误的,那么你得不到微服务承诺的“低耦合、升级不影响、可靠性高”之类的优势,而会比使用Monolithic有更多的麻烦。

  :在实践中,我们常常见到一种架构,后端存储是全部和在一个数据库中,仅仅把前端的业务逻辑拆分到不同的服务进程中,本质上和一个Monolithic一样,只是把模块之间的进程内调用改为进程间调用,这种切分不可取,违反了分布式第一原则,模块耦合没有解决,性能却受到了影响。

  微服务的“Micro”这个词并不是越小越好,而是相对SOA那种粗粒度的服务,我们需要更小更合适的粒度,这种Micro不是无限制的小。

  如果我们将两路(同步)通信与小/微服务结合使用,并根据比如“1个类=1个服务”的原则,那么我们实际上回到了使用Corba、J2EE和分布式对象的20世纪90年代。遗憾的是,新生代的开发人员没有使用分布式对象的经验,因此也就没有认识到这个主意多么糟糕,他们正试图重复历史,只是这次使用了新技术,比如用HTTP取代了RMI或IIOP。

  一个简单的图书管理系统肯定无需微服务架构。既然采用了微服务架构,那么面对的问题空间必然是比较宏大,比如整个电商、CRM。

  如何拆解服务呢?使用什么样的方法拆解服务?业界流行1个类=1个服务、1个方法=1个服务、2 Pizza团队、2周能重写完成等方法,但是这些都缺乏实施基础。我们必须从一些软件设计方法中寻找,面向对象和设计模式适用的问题空间是一个模块,而函数式编程的理念更多的是在代码层面的微观上起作用。Eric Evans 的《领域驱动设计》这本书对微服务架构有很大借鉴意义,这本书提出了一个能将一个大问题空间拆解分为领域和实体之间的关系和行为的技术。目前来说,这是一个最合理的解决拆分问题的方案,透过限界上下文(Bounded Context,下文简称为BC)这个概念,我们能将实现细节封装起来,让BC都能够实现SRP(单一职责)原则。而每个微服务正是BC在实际世界的物理映射,符合BC思路的微服务互相独立松耦合。

  以电商中的订单和商品两个领域举例,按照DDD拆解,他们应该是两个独立的限界上下文,但是订单中肯定是包含商品的,如果贸然拆为两个BC,查询、调用关系就耦合在一起了,甚至有了麻烦的分布式事务的问题,这个关联如何拆解?BC理论认为在不同的BC中,即使是一个术语,他的关注点也不一样,在商品BC中,关注的是属性、规格、详情等等(实际上商品BC这个领域有价格、库存、促销等等,把他作为单独一个BC也是不合理的,这里为了简化例子,大家先认为商品BC就是商品基础信息), 而在订单BC中更关注商品的库存、价格。所以在实际编码设计中,订单服务往往将关注的商品名称、价格等等属性冗余在订单中,这个设计解脱了和商品BC的强关联,两个BC可以独立提供服务,独立数据存储

  小结微服务架构首先要关注的不是RPC/ServiceDiscovery/Circuit Breaker这些概念,也不是Eureka/Docker/SpringCloud/Zipkin这些技术框架,而是服务的边界、职责划分,划分错误就会陷入大量的服务间的相互调用和分布式事务中,这种情况微服务带来的不是便利而是麻烦。DDD给我们带来了合理的划分手段,但是DDD的概念众多,晦涩难以理解,如何抓住重点,合理的运用到微服务架构中呢?我认为如下的几个架构思想是重中之重

  当然这里说的不是服务的分布和集中。服务肯定是分布的,这是大前提,是SOA的本质理念之一。分歧在于对服务的治理,是分布还是集中。

  以一个公司为例:有基层员工 有管理层 有老板,最初大家都听老板指挥,谁干什么谁干什么,根据需要,你可能今天干A事情,明天干B事情,后来人越来越多了,事情也越来越多了,做事情的效率越来越多,管理也很混乱,就开始做部门划分(服务化),专门部门做专门事情的,IT部门只做研发,人事部门只做招聘; 这个时候就无法避免的发生跨部门协作(服务器调用), 但是你怎么知道有这样一个部门可以做这个事情呢,就要依赖行政部门(注册中心),新成立的部门要在行政哪里做一个备案(服务注册),然后公布一下,让其他部门知道了(服务发布),大家就可以在新的工作秩序里面嗨皮的上班了,这个时候依然是在公司的组织架构中运转;

  微服务有一定SOA的概念在里面,只是在粒度中,微服务更加下一点,比如说用户业务服务:登录 注册 个人中心 包含3个业务,都有userService 提供的,但是在微服务中,登录会被独立出来一个服务,注册也会被独立出来,相对SOA的粒度更新,业务场景耦合更低;

  另外微服务强调一个去中心化,上述的公司的组织架构会被打散,没有老板,没有管理层,每一个人都是一个服务,做着自己的事情,虽然没有完全想明白,把自己的理解放出来,大家可以探讨一下

  当然这个单一产品有点模糊,是需要根据自身业务来理解的。例如,一套电商系统就是一个单一产品,虽然它肯定是要包含用户子系统、支付子系统、库存管理子系统等等。传统的构建方式,是通过进程内组件的方式来实现这些子系统,例如 Java 的 Spring Bean 等等。而微服务下,这些子系统是通过彼此独立的服务的方式来构建,服务间通过且仅应该通过 rpc 或者 restful api 的方式来通信。

  SOA 更多的是一种架构风格,一种通过彼此独立的服务来构建系统的风格,它的范畴要比微服务大的多,例如 SOA 架构的系统里,可以有很多产品,外部的访问点可以有多个,任何 SOA 里的系统都可以单独为外界提供服务,用户可能单独使用其中的某个系统,所以 SOA 系统中需要的是一个消息总线;而微服务是一个单一产品,对外只能有一个访问点,回到电商的例子,用户是不可能单独使用库存子系统,用户使用的肯定是一个完整的电商系统,因此微服务需要的是一个 API 网关。

  我理解,除了通过跨进程接口来访问服务外,微服务最核心的是数据独立,即产品中不会有多个服务去共享同一个数据源,一个数据源一定只被一个服务专享,这里要澄清下微服务中同一个服务还包括通过负载均衡下同一类服务的一群服务,这里用“个”代“类”。

  为什么要强调数据独立,现在的架构设计,可以说100%的都会要求架构设计低耦合高内聚,这方面的好处不多说,写过几年程序的都有心得。那么在一个复杂产品(系统)中,最大的耦合是什么呢,实际上是数据耦合,正是数据耦合导致我们的产品成为一个“巨”系统难以拆分。例如电商系统中,显示用户的订单,还需要拿到些例如用户电话号码、地址之类的信息,因为开发时新的开发工程师不了解系统,没有通过用户服务直接从数据库拿了用户信息,就这样订单系统和用户系统耦合了,虽然他们是两个服务。结果就是有一天发现订单系统压力太大,升级或者拆分数据库,却因为和用户的数据耦合在一块不得不连带升级用户的服务,或者想要改进用户的服务,却发现订单系统使用了同一份数据格式,结果用户系统的修改导致了订单系统的不可用。一个成熟的产品,往往要历经数年的开发,数据库一旦共享,数据之间的耦合就会越来越深,最终发现除了推倒重来外没有人再能理清里面的脉络!

  所以,服务间数据独立、仅通过接口互相访问才是评判是否是微服务系统的标志(SOA倒不强调这个),而不是通过服务的大小,实际上,因为微服务的“微”字,给很多人包括我学习时造成了很大的困扰,甚至有位经验丰富的架构师告诉我,微服务就是一个接口一个服务。另外,数据源要求彼此独立,实际上也告诉了我们该如何切分服务,就是通过考察数据源如何独立、隔离,来划分各个服务。

  3.那些 API 网关、熔断、负载均衡和服务发现或者Docker什么的是评判是否是微服务的吗?

  除了 API 网关在概念上是必需的,其它那些实际上不是微服务的核心概念里需要的,它们要么是用来让微服务可以运行的更好的工具,或者是能实际落地的工具。

  API 网关:微服务是一个产品,所以一个产品必然需要一个统一的访问入口,通过 API 网关,客户端的请求才会导航到真正的服务上。

  熔断:微服务概念本身可以不要这个服务,但真正的生产环境是必需的。开发过分布式系统的工程师应该有感受,当某个服务特别慢时,依赖它的服务的请求就会堆积在这里,导致整个系统的处理全部变慢(雪崩效应),这时候通过熔断,我们给过多的请求直接返回错误,至少保证系统能够运行下去。

  负载均衡:负载均衡本身不多说,这里只提一下为什么微服务推荐用 restful api 的方式,restful 是基于 http 的,一方面请求无状态才利于搞负载均衡,另一方面针对 http 的负载方案最多也最廉价。

  服务发现:一个产品有那么多的服务,哪个服务没上线或者崩溃了,依赖它的服务是需要知道的。

  Docker:还是,一个产品有那么多的服务,可能会使用不同的语言编写,可能会使用不同类型的数据源,有时候是MySQL,有时候是 Mongo 这样的 NOSQL,部署一次懂点运维的会知道有多繁琐和容易出错,借助 Docker,和各种编织工具,我们可以像在 iPhone 上安装 APP 一样快速部署,可以说是 Docker 让微服务成为了现实中可落地的方案。

  SOA(面向服务的架构)是一种软件架构,应用程序的不同组件通过通信协议向其他组件提供服务。通信可以包含简单的数据传递,也可以是两个或两个以上的服务相互协调的服务。这些不同的服务执行一些小型的功能,例如验证付款、创建用户帐户或登录。

  SOA不在于如何模块化应用程序,而是如何通过集成分布式、分离维护和部署的软件组件来组合应用程序。通过技术和标准使组件更容易在网络上通信,特别是IP网络。

  SOA中有两个主要角色:服务提供者和服务使用者。软件代理可以同时扮演两个角色。使用者层是用户(应用程序的其他组件或第三方)与SOA交互的点,而提供者层由SOA中的所有服务组成。

  SOA的名字起源于90年代中期,Gartner公司首先认识到了这一软件架构的新兴趋势,并将它推广到全球范围。Gartner成功推动了SOA架构模式的深入发展。不过,分布式服务作为软件架构则可以追溯到80年代初。

  在某种程度上,微服务是面向服务架构演进的下一步。这种架构是开发软件、web或移动应用程序作为独立服务套件的一种特殊方式。服务只提供一个特定的业务功能,如用户管理、用户角色、购物车、搜索引擎、社交媒体登录等。此外,服务与服务之间彼此完全独立,这意味着它们可以用不同的编程语言编写,并使用不同的数据库。集中式的服务管理几乎是不存在的,微服务使用轻量级HTTP、REST或Trift API来进行内部通信。

  微服务这个词起源于2011年5月在威尼斯举行的软件架构师研讨会。2012年5月,还是这一组人决定将“微服务”作为名字。不过在此之前,微软、亚马逊、Netflix和Facebook等主要科技公司已经在微服务领域工作了10多年。还有一些人把他们称为“微web服务”或“细粒度SOA”。

  乍一看,微服务似乎在谈论与SOA同样的事情。然而,微服务领域的先驱马丁·弗劳尔说,应该把SOA看作是一套微服务的超集。

  开发——在这两种架构中,都可以使用不同的编程语言和工具开发服务,将技术的多样性引入到开发团队,在多个团队中组织开发。但是,在SOA中,每个团队需要了解公共通信机制。通过微服务,服务可以独立于其他服务操作和部署。因此,更容易频繁地部署新版本的微服务,或独立扩展服务。

  “边界上下文”——SOA鼓励共享组件,而微服务则试图通过“边界上下文”最小化共享。“边界上下文”指组件和数据作为一个最小依赖项的单个单元的耦合。由于SOA依赖于多个服务来实现业务请求,因此构建在SOA上的系统比微服务慢。

  通信——在SOA中,ESB可能成为影响整个系统的单一故障点。由于每个服务都是通过ESB进行通信,如果其中一个慢下来,就可以通过对该服务的请求阻塞ESB。而微服务的容错能力要好得多。例如,如果一个微服务有内存故障,那么只会影响这一个服务,其他微服务将继续定期处理请求。

  互操作性——SOA通过其消息传递中间件组件,使用多个异构协议。微服务试图通过减少集成的选择数量来简化体系结构模式。因此,如果希望在异构环境中使用不同的协议集成多个系统,则需要考虑SOA。如果所有服务都可以通过相同的远程协议访问,微服务是更好的选择。

  范围——SOA和微服务的主要区别在于大小和范围。微服务的前缀“Micro”指的是内部组件的颗粒度,它比SOA要小得多。微服务中的服务组件通常只有一个目的。而SOA服务包括更多的业务功能,可以视为完整的子系统。

  不能简单地说一个架构比另一个更好,这主要取决于企业构建的应用程序的目的。SOA更适合于需要与其他应用程序集成的更大、更复杂的环境。也就是说,较小的应用程序并不适合SOA,因为它们不需要消息传递中间件组件。另一方面,微服务更适合于较小的、分区良好的基于web的系统。如果正在开发移动或web应用程序,那么微服务将给开发人员更大的控制权。总之,微服务和SOA服务于不同的目的,是完全不同类型的架构。

  微服务这个概念最早是在2011年5月威尼斯的一个软件架构会议上讨论并提出的,用于描述一些作为通用架构风格的设计原则。2012年3月在波兰克拉科夫举行的33rd Degree Conference大会上,Thoughtworks首席咨询师James Lewis做了题为《Microservices - Java, the Unix Way》的演讲(show/67),这次演讲里James讨论了微服务的一些原则和特征,例如单一服务职责、康威定律、自动扩展、DDD等等。

  微服务架构则是由Fred George在2012年的一次技术大会上所提出(oredev.org/oredev2012/2012/sessions/micro-service-architecture.html),在大会的演讲中他讲解了如何分拆服务以及如何利用MQ来进行服务间的解耦,这就是最早的微服务架构雏形。而后由Martin Fowler发扬光大并且在2014年发表了一篇著名的微服务文章(es/microservices.html),这篇文章深入全面的讲解了什么是微服务架构。随后,微服务架构逐渐成为一种非常流行的架构模式,一大批的技术框架和文章涌现出来,越来越多的公司借鉴和使用微服务架构相关的技术。

  然而微服务并不是万能药,我们在实施的过程中不能简单的使用某些个微服务框架或者组件一蹴而就,而是需要将业务、技术和运维有机结合起来,配合同步实施,并且在此过程中还需要趟过很多的坑才能够取得成功。

  本书通过 Dubbo、Spring Cloud、Service Mesh 等技术构建微服务体系,并深入浅出的介绍了微服务架构发展历程、领域驱动设计、稳定性保证的常用手段、分布式事务的一致性方案,以及通过大量的案例探讨微服务落地方案,例如双活体系建设,分布式监控,微服务编排,百亿流量微服务网关的设计与实现,基于支付场景下的微服务改造等,展示了实现微服务架构的完整蓝图,并让读者了解到如何借助于微服务来增强和重构现有的遗留系统。不管你是还没听过或者刚接触过微服务的新手,还是正在尝试借助微服务解放生产力的开发人员或者运维人员,或者是立志于构建高可用可伸缩的微服务体系的架构师,阅读本书,对读者必有裨益。

  本书的每一个章节都是相关领域的专家经过多年的技术积累提炼而成,秉承以理论为基础,以大量企业实战案例为核心,深入全面的介绍了微服务架构的实施方法以及在实施过程中所遇到的问题和解决方案,是一本内容详实、“可落地”的理论实践相结合的技术书籍。

  从软件架构的发展历程讲起,分别对单体架构、SOA架构和微服务架构的演进过程做了深入浅出的讲解,同时也深入介绍了微服务架构的特点,本章以宏观的视角为读者打开微服务的大门。

  本章介绍了领域驱动设计是什么,常见的领域架构有哪些,如何将领域驱动应用到微服务中,以及如何使用领域驱动进行合理的服务划分等,帮助读者在正式学习微服务前修炼内功。

  目前Dubbo已经被阿里巴巴技术团队重新维护并且得到了大力的发展和推广,使用Dubbo依然可以很好的进行微服务建设,本章较为深入的讲解了Dubbo的使用和技巧,以及通过源码的深入分析能够让读者对Dubbo的原理实现有一个全面的认识。

  Spring Boot/Cloud是目前较为流行的微服务框架,本章以大量的实战案例为读者讲解如何才能应用好Spring Cloud框架,以及如何避免在使用过程中遇到的坑。

  当业务发展越来越快,规模也越来越大的情况下,我们所面临的就是如何在服务越来越多的情况下保证微服务架构的稳定性,本章带领读者逐步揭开保障稳定性的常用技巧和手段。

  本章介绍了从本地事务到分布式事务的演变,深入分析了微服务在强一致性场景和最终一致性场景下的解决方案,探讨了二阶段提交协议、三阶段提交协议、TCC 模式、补偿模式、可靠事件模式等。同时,对开源项目的分布式事务进行解读,包括 RocketMQ 和 ServiceComb。

  本章从百亿流量交易系统微服务网关(API Gateway)的现状和面临问题出发,阐述微服务架构与 API 网关的关系,理顺流量网关与业务网关的脉络,带来最全面的 API 网关知识与经验。

  本章以Netflix Conductor框架为核心,从框架的使用和原理深入介绍了什么是微服务编排,为微服务执行复杂的业务逻辑提供了一种新的思路。

  在微服务架构下,服务必将越来越多,在这各情况下如何进行数据统计和分析将变得非常困难,本章将深入讲解如何从不同服务的数据库中抽取数据到统一的大数据平台中,帮忙使用者更方便的进行数据的统计。

  在企业发展规模越来越大的情况下,用户对系统的稳定性要求也越来越高,那么单机房布署势必成为发展的瓶颈,本章将带领读者从零开始以实际案例出发进行同城双活的建设。

  本章从实际的案例出发,在具体的支付业务场景下,从一个新项目开始逐步讲解如何利用领域驱动划分服务,如何利用微服务框架进行服务治理,以及项目完成后怎样提升微服务架构的性能。

  本章介绍了遗留系统的微服务架构改造,梳理了代码分层结构的转变,提出一个新的代码分层思路来应对微服务的流行与普及,并深入思考了遗留系统的债券,深入探讨单体系统拆分服务的方法论。同时,对遗留系统的微服务架构改造的解决方案给出 9 个切实可行的核心实践思路。

  随着微服务的持续发展,下一代微服务架构已然出现,本章将深入介绍Service Mesh发展历程,以及结合具体案例带领读者使用Istio进行具体实践。

  本章重点介绍APM的原理,从零开始开发APM监控系统,还深入介绍Prometheus的安装和原理,以及如何使用Prometheus进行监控和预警。

  典型的企业级应用系统或者互联网应用系统一般都是通过Web提供一组业务服务能力。这类系统包括提供给用户操作的、运行于浏览器中、具有UI的业务逻辑展示和输入部分,运行于服务器端、用后端编程语言构建的业务逻辑处理部分,以及用于存储业务数据的关系数据库或其他类型的存储软件。

  根据软件系统在运行期的表现风格和部署结构,我们可以粗略地将其划分为两大类:

  1) 整个系统的所有功能单元,整体部署到同一个进程(所有代码可以打包成1个或多个文件),我们可以称之为“单体架构”(Monolithic Architecture);

  2) 整个系统的功能单元分散到不同的进程,然后由多个进程共同提供不同的业务能力,我们称之为“分布式架构”(Distributed Architecture);

  任何一个体系(产品、平台、商业模式等)如果想要发展壮大,途径只有两个模式: a) 容器模式:从外部提供越来越多的资源和能力,注入到体系的内部,不断的从内扩充自己。单体架构的系统类似这种模式。 b) 生态模式:以自己的核心能力为内核,持续的在外部吸引合作者,形成一个可以不断成长的生态体系。分布式架构越来越像这种模式。

  对于单体架构,我们根据设计期和开发实现期的不同模式和划分结构,可以分为:

  简单单体模式:代码层面没有拆分,所有的业务逻辑都在一个项目(project)里打包成一个二进制的编译后文件,通过这个文件进行部署,并提供业务能力;

  MVC模式:系统内每个模块的功能组件按照不同的职责划分为模型(Model)、视图(View)、控制器(Controller)等角色,并以此来组织研发实现工作;

  前后端分离模式:将前后端代码耦合的设计改为前端逻辑和后端逻辑独立编写实现的处理模式;

  组件模式:系统的每一个模块拆分为一个子项目(subproject),每个模块独立编译打包成一个组件,然后所有需要的组件一起再部署到同一个容器里;

  类库模式:A系统需要复用B系统的某些功能,这时可以直接把B系统的某些组件作为依赖库,打包到A系统来使用。

  面向服务架构(Service Oriented Architecture,SOA):以业务服务的角度和服务总线的方式(一般是WebService与ESB)考虑系统架构和企业IT治理;

  分布式服务架构(Distributed Service Architecture,DSA):基于去中心化的分布式服务框架与技术,考虑系统架构和服务治理;

  微服务架构(MicroServices Architecture,MSA):微服务架构可以看做是面向服务架构和分布式服务架构的拓展,使用更细粒度的服务(所以叫微服务)和一组设计准则来考虑大规模的复杂系统架构设计。

  此外,传统的企业集成领域的EAI架构模式,本身还是各个系统独立部署,但是各系统之间的部分业务使用特定的技术打通了,因此我们可以看做是单体和分布式之间的过渡状态。

  简单单体模式是最简单的架构风格,所有的代码全都在一个项目中。这样研发团队的任何一个人都可以随时修改任意的一段代码,或者增加一些新的代码。开发人员也可以只在自己的电脑上就可以随时开发、调试、测试整个系统的功能。也不需要额外的一些依赖条件和准备步骤,我们就可以直接编译打包整个系统代码,创建一个可以发布的二进制版本。这种方式对于一个新团队的创立初期,需要迅速开始从0到1,抓住时机实现产品最短时间推向市场,可以省去各种额外的设计,直接上手干活,争取了时间,因而是非常有意义的。

  但是这种简单粗暴的方式对于一个系统的长期稳定发展确实有很多坏处的。但是正如一个新出生的小动物野蛮生长,如果没有正确的教导和规则的约束,最后成为一个忠实的导盲犬还是一条携带病毒的狂犬,就不得而知了。

  首先,简单单体模式的系统存在代码严重耦合的问题。所有的代码都在一起,就算是按照package来切分了不同的模块,各不同模块的代码还是可以直接相互引用,这就导致了系统内的对象间依赖关系混乱,修改一处代码,可能会影响一大片的功能无法正常使用。为了保障每次上线时的可靠性,我们必须花费很多的精力做大量的回归测试,对于经常需要修改维护的系统,这种代价是可怕的。

  第二,简单单体模式的系统变更对部署影响大,并且这个问题是所有的单体架构系统都存在的问题。系统作为一个单体部署,每次发布的部署单元就是一个新版本的整个系统,系统内的任何业务逻辑调整都会导致整个系统的重新打包,部署、停机、再重启,进而导致了系统的停机发布时间较长。每次发布上线都是生产系统的重大变更,这种部署模式大大提升了系统风险,降低了系统的可用性。

  第三,简单单体模式的系统影响开发效率。如果一个使用Java的简单单体项目代码超过100万行,那么在一台笔记本电脑上修改了代码后执行自动编译,可能需要等待十分钟以上,并且内存可能不够编译过程使用,这是非常难以忍受的。

  第四,简单单体模式打包后的部署结构可能过于庞大,导致业务系统启动很慢,进而也会影响系统的可用性。这一条也是所有单体架构的系统都有的问题。

  第五,扩展性受限,也是所有单体架构的一个问题。如果任何一个业务存在性能问题,那么都需要考虑多部署几个完整的实例的集群,或者再加上负载均衡设备,才能保证整个系统的性能可以支撑用户的使用。

  所以,简单单体模式比较适用于规模较小的系统,特别是需要快速推出原型实现,以质量换速度的场景。

  随着IT技术逐渐成为各行各业的基础性支撑技术之一,并且很多大型公司内部的IT系统规模越来越大,传统架构思想的不足越来越明显。针对如何更好的利用企业内部的各个IT系统能力,解决数据孤岛问题,整合业务功能,先是出现了企业应用集成(Enterprise Application Integration,EAI)解决方案,即通过对现有各系统的数据接口改造,实现系统互通(特别是异构系统),这样不同系统的数据就可以被整合到一起了。在大量的EAI项目实施的基础上,架构设计关注的不仅仅是单个的项目,而是企业的整个IT系统集合。架构师们以超越单体架构的分布式思想和业务服务能力的角度来看待问题,这样面向服务架构即SOA就发展起来了。

  2006年IBM、Oracle、SAP、普元公司等一起建立了OSOA联盟,共同制定 SCA/SDO标准。2007年4月,国际标准组织OASIS宣布成立OASIS Open Composite Services Architecture (Open CSA) 委员会,自此,OSOA的职能移转至Open CSA组织。 SOA的概念最初由Gartner公司提出,2000 年以后,业界普遍认识到SOA思想的重要性。从2005年开始,SOA推广和普及工作开始加速,几乎所有关心软件行业发展的人士都开始把目光投向SOA,各大厂商也通过建立厂商间的协作组织共同努力制定中立的SOA标准:SCA/SDO规范。同时产生了一个Apache基金会顶级项目Tuscany作为SCA/SDO的参考实现。SCA和SDO构成了SOA编程模型的基础。经过10多年的广泛探索研究和实际应用,SOA本身的理论、相关技术、工具等也已经发展到成熟、稳定的阶段,在信息化系统建设时普遍采用了SOA架构思想。

  面向服务架构(SOA)是一种建设企业IT生态系统的架构指导思想。SOA的关注点是服务。服务最基本的业务功能单元,由平台中立性的接口契约来定义。通过将业务系统服务化,可以将不同模块解耦,各种异构系统间可以轻松实现服务调用、消息交换和资源共享。

  1) 从宏观的视角来看,不同于以往的孤立业务系统,SOA强调整个企业IT生态环境是一个大的整体。整个IT生态中的所有业务服务构成了企业的核心IT资源。各系统的业务拆解为不同粒度和层次的模块和服务,服务可以组装到更大的粒度,不同来源的服务可以编排到同一个处理流程,实现非常复杂的集成场景和更加丰富的业务功能。

  2) 从研发的视角来看,系统的复用可以从以前代码级的粒度,扩展到业务服务的粒度;能够快速应对业务需求和集成需求的变更。

  3) 从管理的角度来看,SOA从更高的层次对整个企业IT生态进行统一的设计与管理,对消息处理与服务调用进行监控,优化资源配置,降低系统复杂度和综合成本,为业务流程梳理和优化提供技术支撑。

  在SOA体系下,应用软件被划分为具有不同功能的服务单元,并通过标准的软件接口把这些服务联系起来,以SOA架构实现的企业应用可以更灵活快速地响应企业业务变化,实现新旧软件资产的整合和复用,降低软件整体拥有成本。

  SOA的实施对整个IT生态环境都有重要的影响,作为一种重大的IT变革和技术决策,必然要自上而下的进行。必须获得管理层的支持,由技术决策层面直接推动,并和技术部门、相关业务部门一起,根据目前各个IT业务系统的现状,统一规划SOA战略和分阶段目标,制定可行方案与计划步骤,逐步推进实施。

  SOA的落地方式与水平,跟企业IT特点、服务能力和发展阶段直接相关。目前常见的落地方式主要有分布式服务化和集中式管理两种。

  1) 分布式服务化 互联网类型的企业,业务与技术发展快,数据基数与增量都大,并发访问量高,系统间依赖关系复杂、调用频繁,分布式服务化与服务治理迫在眉睫。通过统一的服务化技术手段,进一步实现服务的注册与寻址、服务调用关系查找、服务调用与消息处理监控、服务质量与服务降级等等。现有的一些分布式服务化技术有dubbo(基于java)、finagle(基于scala)和ICE(跨平台)等。

  2) 集中式管理化 传统企业的IT内部遗留系统包袱较重,资源整合很大一部分是需要打通新旧技术体系的任督二脉,所以更偏重于以esb作为基础支撑技术,以整合集成为核心,将各个新旧系统的业务能力逐渐的在ESB容器上聚合和集成起来。比较流行的商业ESB有IBM的WMB和oracle的osb,开源esb有mule、servicemix、jbossesb、wso2esb和openesb。

  商业的esb,一般来说除了功能丰富以外,配套设置都比较齐全,对于比较简单的场景来说可以做到开箱即用,维护性也比较强,但是一般来说过于复杂非常难用、内部基本是黑盒、而且很贵。 开源的esb,由于开发成本和通用性开放性的考虑,往往在esb server上做的比较强大、扩展性比较好,但是配套设置做的很差(这也是绝大多数开源项目共有的问题,不仅是开源esb的问题)。对企业来说可管理性非常重要,选择开源esb的话,这一块需要结合企业的实际情况,一步步的积累,下大功夫来自己做好。

  一方面,集中式管理的SOA,其优势在于管理和集成企业内部各处散落的业务服务能力,同时一个明显的不足在于其中心化的架构方法,并不同解决各个系统自己内部的问题。另一方面,随着自动化测试技术、轻量级容器技术等相关技术的发展,分布式服务技术越来越像微服务架构方向发展。

  EIP(Enterprise Integration Patterns,企业集成模式)是集成领域的圣经,也是各种MOM和ESB的理论基础。我们在MQ和ESB中常见的各种概念和术语,基本都是来自于EIP,比如消息代理、消息通道、消息端点、消息路由、消息转换、消息增强、信息分支、消息聚合、消息分解、消息重排等等,并在《企业集成模式:设计、构建及部署消息传递解决方案》一书中详细的描述了它们的内容与特点。 EIP的直接实现一般叫EIP框架,开源的知名EIP框架有两个:camel和spring integration。EIP可以作为ESB的基础骨架,在这个基础上填充其他必要的部分,定制出来一个ESB容器。 EIP的介绍可以看这里:

  SOA关注于系统的服务化,不同系统服务间的相互通信就成为了一个重要的话题。并且随着RPC和MQ技术的发展,这两种技术逐渐成为SOA的两大基石,也是分布式技术体系里的重要基础设施。

  1) RPC(Remote Procedure Call,远程过程调用) 两个不同系统间的数据通信,往往可以通过socket+自定义数据报文来实现。但是这种方式比较繁琐,需要针对每个通信场景定义自己的数据格式和报文标准,甚至交互的行为、异常和错误的处理等等。有没有一种通用的技术手段呢?答案就是RPC技术。 RPC是一种通用性的系统通信手段,使得我们可以像调用本地方法一样调用远程系统提供的方法。 一个场景的RPC机制如图1-7:

  RPC的调用关系里,我们把提供具体的调用方法的系统叫服务提供者(Provider),调用服务的系统称为服务消费者(Consumer)。把对象转换为以便于网络传输的二进制或文本数据的过程,叫做序列化(Serialization);二进制或文本数据再还原为对象的过程,叫做反序列化(Deserialization)。 我们可以看到,典型的RPC处理机制包括两部分:

  RR(Request-Response)模式,又叫请求响应模式,指每个调用都要有具体的返回结果信息。

  Future模式,又叫异步模式,返回拿到一个Future对象,然后执行完获取到返回结果信息。

  Callback模式,又叫回调模式,处理完请求以后,将处理结果信息作为参数传递给回调函数进行处理。

  这四种调用模式中,前两种最常见,后两种一般是RR和Oneway方式的包装,所以从本质上看,RPC一般对于客户端的来说是一种同步的远程服务调用技术。与其相对应。

  电气网

 
标签: 电子元器件
打赏
 
更多>同类资讯
0相关评论

推荐图文
推荐资讯
点击排行
网站首页  |  联系客服  |  网站地图  |  排名推广  |  广告服务  |  RSS订阅  |  违规举报