任何一种架构选择都必然有利有弊。特别是在微服务架构方面，其实际推行往往会给运营体系带来深远影响甚至是严重的负面结果。相对于单一且经过严格定义的大规模开发项目，微服务架构要求大家面对由众多小型服务所构成的复杂生态系统。鉴于此，如果大家不具备一定程度的基准把控能力，我实在不建议各位盲目迈向微服务这一新兴架构领域。
作者 Martin Fowler
& & & & & & & & & & & &&
在同人们探讨微服务架构方案的实际应用时，我发现大家普遍持一种过度乐观的态度。开发人员乐于处理小型项目单元，并期待着能够由此实现超越大规模技术型项目的出色模块化成效。在这里我要强调，任何一种架构选择都必然有利有弊。特别是在微服务架构方面，其实际推行往往会给运营体系带来深远影响甚至是严重的负面结果。相对于单一且经过严格定义的大规模开发项目，微服务架构要求大家面对由众多小型服务所构成的复杂生态系统。鉴于此，如果大家不具备一定程度的基准把控能力，我实在不建议各位盲目迈向微服务这一新兴架构领域。
快速配置:大家应该能够在几个小时之内配置并启用一台全新服务器设备。一般来说采用云计算方案能够大大缩短这一处理流程，不过我们同样可以在无需依赖完整云服务的前提下实现这一目标。为了尽可能将配置周期压缩到最低程度，大家需要在流程中引入大量自动化机制——事实上，原本的配置方案并不是非要自动化参与不可，但选择了微服务架构之后自动化将成为其中不可或缺的一环。
基础监控:由于微服务架构要求我们将大量松散耦合的服务统一在同一套生产流程中并实现其协作，因此大家往往很难单纯依靠测试环境来检测出未来可能发生的意外故障。这样一来，严格和监控体系就成了快速检测并定位严重问题的不二选择。作为底限，我们至少需要对各类技术问题进行检测（包括错误计数以及服务可用性检查等），此外对业务问题的监控同样至关重要（例如检测下单情况等）。如果突发性问题意外出现，大家则需要确保自己能够快速回滚至原先的正常运行状态，而这又将引入新的恢复机制……
应用程序快速部署:由于存在大量需要管理的服务，大家必须有能力快速将其部署到测试环境以及生产流程当中。通常情况下，我们只能利用部署流水线（Deployment Pipeline）来保证整个过程在数小时之内彻底完成。在早期阶段，大家还可以通过人工方式加以干预，但在后续运作当中所有相关工作都要由自动化机制负责完成。
由此提出的能力要求意味着企业需要在组织结构上作出重大转变——即在开发人员与运营团队之间建立起紧密的协作纽带：也就是DevOps文化。这种协作方式的意义在于确保配置及部署工作能够快速得以完成，同时也能够让各位在检测到意外状况时快速作出反应。具体而言，任何意外状况都需要开发团队与运营部门双方的共同介入，二者将携手完成问题的实时修复并分析引发状况的根本性原因、从而确保底层问题切实得到修复。
拥有了上述协作体系之后，大家才算是做好了将微服务架构引入首套系统的准备。接下来我们将这套系统部署在生产环境内并加以使用，通过实际管理了解保障其正常运行及DevOps协作关系顺利起效的经验与心得。拿出时间与耐心，认真体会由此积累起的宝贵素材，并在逐步提升服务容纳能力之后尝试启用更多服务项目。
如果大家还达不到上述要求，请千万不要急于催促自己的开发团队将微服务系统引入到生产环境当中。事实上，这些能力在运行大规模系统时同样极为重要。尽管目前大部分软件开发部门都无法通过以上这些严苛的考验，但请注意，此类能力在任何业务环境下都应具备很高的培养优先级。
要进一步增强服务支持数量，我们则不可避免地面对更多复杂的要求。大家需要在多服务环境下追踪业务事务处理状态，同时充分利用持续交付（Continuous Delivery）机制实现配置与部署的自动化处理。为生产为核心的团队也必须针对这方面要求作出转变。除此之外，大家还需要对企业内部的开发环境进行重塑，从而保证开发人员能够更轻松地在不同资源库、代码库以及编程语言之间纵横往来。感兴趣的朋友可以点击此处了解更多关于成熟模式的相关内容，我的同行们利用这些方案帮助企业顺利完成了微服务架构的实施——相信在未来几年内，还将有更多结论性指导意见可供大家参考。
原文链接：
/bliki/MicroservicePrerequisites.html?from=message&isappinstalled=0
后方可回复
如果没有账号可以
一个帐号。
该话题的其他文章
该作者的其他文章
欢迎来到普元技术社区。
普元是国内领先的软件基础平台与解决方案提供商，主要面向大中型企业、政府机构及软件开发商提供SOA、大数据、云计算三大领域的软件基础平台及解决方案，用以满足上述组织信息化建设对关键技术的需求，帮助上述组织的业务在云计算和移动互联时代向数字化转型。普元系国家规划布局内重点软件企业，并是国际标准组织OASIS成员、SOA国际标准SCA/SDO的主要参与制定者、全国信标委SOA分技术委员会SOA与Web服务工作组副组长单位、全国信标委云计算工作组成员单位。IT - 古镇网_腾讯新闻_今日头条新闻_综合新闻资讯发布网站!
IT 07-11 13:2207-11 13:2007-11 13:1907-11 13:1907-11 13:1507-11 13:1307-11 13:1107-11 13:0607-11 13:0607-11 13:0207-11 13:0107-11 13:0007-11 13:0007-11 12:5307-11 12:5007-11 12:4107-11 12:3907-11 12:3607-11 12:3207-11 12:2807-11 12:2807-11 12:2807-11 12:2807-11 12:2807-11 12:2007-11 12:1907-11 12:1807-11 12:1707-11 12:1707-11 12:1607-11 12:1007-11 12:0907-11 12:0807-11 12:0207-11 12:0207-11 12:0207-11 12:0007-11 12:0007-11 11:5707-11 11:5207-11 11:5107-11 11:5007-11 11:4907-11 11:4607-11 11:4407-11 11:4407-11 11:4407-11 11:4307-11 11:4307-11 11:4307-11 11:4107-11 11:3807-11 11:3707-11 11:3607-11 11:3207-11 11:3007-11 11:3007-11 11:2807-11 11:2807-11 11:2707-11 11:2707-11 11:2707-11 11:2707-11 11:2407-11 11:2407-11 11:2307-11 11:2307-11 11:1907-11 11:1707-11 11:1607-11 11:1407-11 11:1407-11 11:1207-11 11:1207-11 11:1107-11 11:1007-11 11:0907-11 11:0707-11 11:0707-11 11:0607-11 11:0207-11 11:0007-11 10:5307-11 10:5007-11 10:4907-11 10:4807-11 10:4707-11 10:4707-11 10:4607-11 10:4607-11 10:4507-11 10:4507-11 10:4407-11 10:4407-11 10:4307-11 10:4307-11 10:4007-11 10:3807-11 10:3707-11 10:3707-11 10:3607-11 10:3507-11 10:3407-11 10:3407-11 10:3207-11 10:3007-11 10:3007-11 10:3007-11 10:2807-11 10:2707-11 10:2607-11 10:2607-11 10:2607-11 10:2507-11 10:2307-11 10:2307-11 10:2107-11 10:2107-11 10:1907-11 10:1807-11 10:1607-11 10:1407-11 10:1307-11 10:1307-11 10:1107-11 10:1007-11 10:1007-11 10:0907-11 10:0607-11 10:0607-11 10:0507-11 10:0407-11 10:0407-11 10:0407-11 10:0307-11 10:0207-11 10:0107-11 10:0007-11 10:0007-11 10:0007-11 09:5607-11 09:5307-11 09:5307-11 09:4907-11 09:4707-11 09:4507-11 09:4507-11 09:4407-11 09:4307-11 09:4207-11 09:3707-11 09:3607-11 09:3307-11 09:3207-11 09:3007-11 09:2607-11 09:2307-11 09:2307-11 09:2307-11 09:2307-11 09:2307-11 09:2307-11 09:2207-11 09:2207-11 09:2107-11 09:2007-11 09:1807-11 09:1707-11 09:1707-11 09:1607-11 09:1607-11 09:1607-11 09:1207-11 09:1007-11 09:0907-11 09:0807-11 09:0807-11 09:0507-11 09:0307-11 09:0307-11 09:0107-11 09:0007-11 09:0007-11 09:0007-11 09:0007-11 09:0007-11 08:5907-11 08:5907-11 08:5707-11 08:5707-11 08:5707-11 08:5707-11 08:5707-11 08:5607-11 08:5507-11 08:5507-11 08:5407-11 08:3707-11 08:3607-11 08:33
声明：本网部分信息转载于其他网站，如稿件涉及版权等问题，请联系我们！实施微服务，我们需要哪些基础框架？
发布于 日 |
微服务(MicroServices)架构是当前互联网业界的一个技术热点，圈里有不少同行朋友当前有计划在各自公司开展微服务化体系建设，他们都有相同的疑问：一个微服务架构有哪些技术关注点(technical concerns)？需要哪些基础框架或组件来支持微服务架构？这些框架或组件该如何选型？笔者之前在两家大型互联网公司参与和主导过大型服务化体系和框架建设，同时在这块也投入了很多时间去学习和研究，有一些经验和学习心得，可以和大家一起分享。
服务注册、发现、负载均衡和健康检查
和单块(Monolithic)架构不同，微服务架构是由一系列职责单一的细粒度服务构成的分布式网状结构，服务之间通过轻量机制进行通信，这时候必然引入一个服务注册发现问题，也就是说服务提供方要注册通告服务地址，服务的调用方要能发现目标服务，同时服务提供方一般以集群方式提供服务，也就引入了负载均衡和健康检查问题。根据负载均衡LB所在位置的不同，目前主要的服务注册、发现和负载均衡方案有三种：
第一种是集中式LB方案，如下图Fig 1，在服务消费者和服务提供者之间有一个独立的LB，LB通常是专门的硬件设备如F5，或者基于软件如LVS，HAproxy等实现。LB上有所有服务的地址映射表，通常由运维配置注册，当服务消费方调用某个目标服务时，它向LB发起请求，由LB以某种策略（比如Round-Robin）做负载均衡后将请求转发到目标服务。LB一般具备健康检查能力，能自动摘除不健康的服务实例。服务消费方如何发现LB呢？通常的做法是通过DNS，运维人员为服务配置一个DNS域名，这个域名指向LB。
Fig 1, 集中式LB方案
集中式LB方案实现简单，在LB上也容易做集中式的访问控制，这一方案目前还是业界主流。集中式LB的主要问题是单点问题，所有服务调用流量都经过LB，当服务数量和调用量大的时候，LB容易成为瓶颈，且一旦LB发生故障对整个系统的影响是灾难性的。另外，LB在服务消费方和服务提供方之间增加了一跳(hop)，有一定性能开销。
第二种是进程内LB方案，针对集中式LB的不足，进程内LB方案将LB的功能以库的形式集成到服务消费方进程里头，该方案也被称为软负载(Soft Load Balancing)或者客户端负载方案，下图Fig 2展示了这种方案的工作原理。这一方案需要一个服务注册表(Service Registry)配合支持服务自注册和自发现，服务提供方启动时，首先将服务地址注册到服务注册表（同时定期报心跳到服务注册表以表明服务的存活状态，相当于健康检查），服务消费方要访问某个服务时，它通过内置的LB组件向服务注册表查询（同时缓存并定期刷新）目标服务地址列表，然后以某种负载均衡策略选择一个目标服务地址，最后向目标服务发起请求。这一方案对服务注册表的可用性(Availability)要求很高，一般采用能满足高可用分布式一致的组件（例如Zookeeper, Consul, Etcd等）来实现。
Fig 2, 进程内LB方案
进程内LB方案是一种分布式方案，LB和服务发现能力被分散到每一个服务消费者的进程内部，同时服务消费方和服务提供方之间是直接调用，没有额外开销，性能比较好。但是，该方案以客户库(Client Library)的方式集成到服务调用方进程里头，如果企业内有多种不同的语言栈，就要配合开发多种不同的客户端，有一定的研发和维护成本。另外，一旦客户端跟随服务调用方发布到生产环境中，后续如果要对客户库进行升级，势必要求服务调用方修改代码并重新发布，所以该方案的升级推广有不小的阻力。
进程内LB的案例是
Netflix的开源服务框架，对应的组件分别是：Eureka服务注册表，Karyon服务端框架支持服务自注册和健康检查，Ribbon客户端框架支持服务自发现和软路由。另外，阿里开源的服务框架Dubbo也是采用类似机制。
第三种是主机独立LB进程方案，该方案是针对第二种方案的不足而提出的一种折中方案，原理和第二种方案基本类似，不同之处是，他将LB和服务发现功能从进程内移出来，变成主机上的一个独立进程，主机上的一个或者多个服务要访问目标服务时，他们都通过同一主机上的独立LB进程做服务发现和负载均衡，见下图Fig 3。
Fig 3 主机独立LB进程方案
该方案也是一种分布式方案，没有单点问题，一个LB进程挂了只影响该主机上的服务调用方，服务调用方和LB之间是进程内调用，性能好，同时，该方案还简化了服务调用方，不需要为不同语言开发客户库，LB的升级不需要服务调用方改代码。该方案的不足是部署较复杂，环节多，出错调试排查问题不方便。
该方案的典型案例是Airbnb的SmartStack服务发现框架，对应组件分别是：Zookeeper作为服务注册表，Nerve独立进程负责服务注册和健康检查，Synapse/HAproxy独立进程负责服务发现和负载均衡。Google最新推出的基于容器的PaaS平台Kubernetes，其内部服务发现采用类似的机制。
服务前端路由
微服务除了内部相互之间调用和通信之外，最终要以某种方式暴露出去，才能让外界系统（例如客户的浏览器、移动设备等等）访问到，这就涉及服务的前端路由，对应的组件是服务网关(Service Gateway)，见图Fig 4，网关是连接企业内部和外部系统的一道门，有如下关键作用：
服务反向路由，网关要负责将外部请求反向路由到内部具体的微服务，这样虽然企业内部是复杂的分布式微服务结构，但是外部系统从网关上看到的就像是一个统一的完整服务，网关屏蔽了后台服务的复杂性，同时也屏蔽了后台服务的升级和变化。
安全认证和防爬虫，所有外部请求必须经过网关，网关可以集中对访问进行安全控制，比如用户认证和授权，同时还可以分析访问模式实现防爬虫功能，网关是连接企业内外系统的安全之门。
限流和容错，在流量高峰期，网关可以限制流量，保护后台系统不被大流量冲垮，在内部系统出现故障时，网关可以集中做容错，保持外部良好的用户体验。
监控，网关可以集中监控访问量，调用延迟，错误计数和访问模式，为后端的性能优化或者扩容提供数据支持。
日志，网关可以收集所有的访问日志，进入后台系统做进一步分析。
Fig 4, 服务网关
除以上基本能力外，网关还可以实现线上引流，线上压测，线上调试(Surgical debugging)，金丝雀测试(Canary Testing)，数据中心双活(Active-Active HA)等高级功能。
网关通常工作在7层，有一定的计算逻辑，一般以集群方式部署，前置LB进行负载均衡。
开源的网关组件有Netflix的Zuul，特点是动态可热部署的过滤器(filter)机制，其它如HAproxy，Nginx等都可以扩展作为网关使用。
在介绍过服务注册表和网关等组件之后，我们可以通过一个简化的微服务架构图(Fig 5)来更加直观地展示整个微服务体系内的服务注册发现和路由机制，该图假定采用进程内LB服务发现和负载均衡机制。在下图Fig 5的微服务架构中，服务简化为两层，后端通用服务（也称中间层服务Middle Tier Service）和前端服务（也称边缘服务Edge Service，前端服务的作用是对后端服务做必要的聚合和裁剪后暴露给外部不同的设备，如PC，Pad或者Phone）。后端服务启动时会将地址信息注册到服务注册表，前端服务通过查询服务注册表就可以发现然后调用后端服务；前端服务启动时也会将地址信息注册到服务注册表，这样网关通过查询服务注册表就可以将请求路由到目标前端服务，这样整个微服务体系的服务自注册自发现和软路由就通过服务注册表和网关串联起来了。如果以面向对象设计模式的视角来看，网关类似Proxy代理或者Fa?ade门面模式，而服务注册表和服务自注册自发现类似IoC依赖注入模式，微服务可以理解为基于网关代理和注册表IoC构建的分布式系统。
Fig 5, 简化的微服务架构图
当企业微服务化以后，服务之间会有错综复杂的依赖关系，例如，一个前端请求一般会依赖于多个后端服务，技术上称为1 -& N扇出(见图Fig 6)。在实际生产环境中，服务往往不是百分百可靠，服务可能会出错或者产生延迟，如果一个应用不能对其依赖的故障进行容错和隔离，那么该应用本身就处在被拖垮的风险中。在一个高流量的网站中，某个单一后端一旦发生延迟，可能在数秒内导致所有应用资源(线程，队列等)被耗尽，造成所谓的雪崩效应(Cascading Failure，见图Fig 7)，严重时可致整个网站瘫痪。
Fig 6, 服务依赖
Fig 7, 高峰期单个服务延迟致雪崩效应
经过多年的探索和实践，业界在分布式服务容错一块探索出了一套有效的容错模式和最佳实践，主要包括：
电路熔断器模式(Circuit Breaker Patten), 该模式的原理类似于家里的电路熔断器，如果家里的电路发生短路，熔断器能够主动熔断电路，以避免灾难性损失。在分布式系统中应用电路熔断器模式后，当目标服务慢或者大量超时，调用方能够主动熔断，以防止服务被进一步拖垮；如果情况又好转了，电路又能自动恢复，这就是所谓的弹性容错，系统有自恢复能力。下图Fig 8是一个典型的具备弹性恢复能力的电路保护器状态图，正常状态下，电路处于关闭状态(Closed)，如果调用持续出错或者超时，电路被打开进入熔断状态(Open)，后续一段时间内的所有调用都会被拒绝(Fail Fast)，一段时间以后，保护器会尝试进入半熔断状态(Half-Open)，允许少量请求进来尝试，如果调用仍然失败，则回到熔断状态，如果调用成功，则回到电路闭合状态。
Fig 8, 弹性电路保护状态图
舱壁隔离模式(Bulkhead Isolation Pattern)，顾名思义，该模式像舱壁一样对资源或失败单元进行隔离，如果一个船舱破了进水，只损失一个船舱，其它船舱可以不受影响 。线程隔离(Thread Isolation)就是舱壁隔离模式的一个例子，假定一个应用程序A调用了Svc1/Svc2/Svc3三个服务，且部署A的容器一共有120个工作线程，采用线程隔离机制，可以给对Svc1/Svc2/Svc3的调用各分配40个线程，当Svc2慢了，给Svc2分配的40个线程因慢而阻塞并最终耗尽，线程隔离可以保证给Svc1/Svc3分配的80个线程可以不受影响，如果没有这种隔离机制，当Svc2慢的时候，120个工作线程会很快全部被对Svc2的调用吃光，整个应用程序会全部慢下来。
限流(Rate Limiting/Load Shedder)，服务总有容量限制，没有限流机制的服务很容易在突发流量(秒杀，双十一)时被冲垮。限流通常指对服务限定并发访问量，比如单位时间只允许100个并发调用，对超过这个限制的请求要拒绝并回退。
回退(fallback)，在熔断或者限流发生的时候，应用程序的后续处理逻辑是什么？回退是系统的弹性恢复能力，常见的处理策略有，直接抛出异常，也称快速失败(Fail Fast)，也可以返回空值或缺省值，还可以返回备份数据，如果主服务熔断了，可以从备份服务获取数据。
Netflix将上述容错模式和最佳实践集成到一个称为Hystrix的开源组件中，凡是需要容错的依赖点(服务，缓存，数据库访问等)，开发人员只需要将调用封装在Hystrix Command里头，则相关调用就自动置于Hystrix的弹性容错保护之下。Hystrix组件已经在Netflix经过多年运维验证，是Netflix微服务平台稳定性和弹性的基石，正逐渐被社区接受为标准容错组件。
微服务化以后，为了让业务开发人员专注于业务逻辑实现，避免冗余和重复劳动，规范研发提升效率，必然要将一些公共关注点推到框架层面。服务框架(Fig 9)主要封装公共关注点逻辑，包括：
Fig 9, 服务框架
服务注册、发现、负载均衡和健康检查，假定采用进程内LB方案，那么服务自注册一般统一做在服务器端框架中，健康检查逻辑由具体业务服务定制，框架层提供调用健康检查逻辑的机制，服务发现和负载均衡则集成在服务客户端框架中。
监控日志，框架一方面要记录重要的框架层日志、metrics和调用链数据，还要将日志、metrics等接口暴露出来，让业务层能根据需要记录业务日志数据。在运行环境中，所有日志数据一般集中落地到企业后台日志系统，做进一步分析和处理。
REST/RPC和序列化，框架层要支持将业务逻辑以HTTP/REST或者RPC方式暴露出来，HTTP/REST是当前主流API暴露方式，在性能要求高的场合则可采用Binary/RPC方式。针对当前多样化的设备类型(浏览器、普通PC、无线设备等)，框架层要支持可定制的序列化机制，例如，对浏览器，框架支持输出Ajax友好的JSON消息格式，而对无线设备上的Native App，框架支持输出性能高的Binary消息格式。
配置，除了支持普通配置文件方式的配置，框架层还可集成动态运行时配置，能够在运行时针对不同环境动态调整服务的参数和配置。
限流和容错，框架集成限流容错组件，能够在运行时自动限流和容错，保护服务，如果进一步和动态配置相结合，还可以实现动态限流和熔断。
管理接口，框架集成管理接口，一方面可以在线查看框架和服务内部状态，同时还可以动态调整内部状态，对调试、监控和管理能提供快速反馈。Spring Boot微框架的Actuator模块就是一个强大的管理接口。
统一错误处理，对于框架层和服务的内部异常，如果框架层能够统一处理并记录日志，对服务监控和快速问题定位有很大帮助。
安全，安全和访问控制逻辑可以在框架层统一进行封装，可做成插件形式，具体业务服务根据需要加载相关安全插件。
文档自动生成，文档的书写和同步一直是一个痛点，框架层如果能支持文档的自动生成和同步，会给使用API的开发和测试人员带来极大便利。Swagger是一种流行Restful API的文档方案。
当前业界比较成熟的
微服务框架有Netflix的Karyon/Ribbon，Spring的Spring Boot/Cloud，阿里的Dubbo等。
运行期配置管理
服务一般有很多依赖配置，例如访问数据库有连接字符串配置，连接池大小和连接超时配置，这些配置在不同环境(开发/测试/生产)一般不同，比如生产环境需要配连接池，而开发测试环境可能不配，另外有些参数配置在运行期可能还要动态调整，例如，运行时根据流量状况动态调整限流和熔断阀值。目前比较常见的做法是搭建一个运行时配置中心支持微服务的动态配置，简化架构如下图(Fig 10):
Fig 10, 服务配置中心
动态配置存放在集中的配置服务器上，用户通过管理界面配置和调整服务配置，具体服务通过定期拉(Scheduled Pull)的方式或者服务器推(Server-side Push)的方式更新动态配置，拉方式比较可靠，但会有延迟同时有无效网络开销(假设配置不常更新)，服务器推方式能及时更新配置，但是实现较复杂，一般在服务和配置服务器之间要建立长连接。配置中心还要解决配置的版本控制和审计问题，对于大规模服务化环境，配置中心还要考虑分布式和高可用问题。
配置中心比较成熟的开源方案有百度的Disconf，360的QConf，Spring的Cloud Config和阿里的Diamond等。
Netflix的微服务框架
Netflix是一家成功实践微服务架构的互联网公司，几年前，Netflix就把它的几乎整个微服务框架栈开源贡献给了社区，这些框架和组件包括：
Eureka:　服务注册发现框架
Zuul:　服务网关
Karyon:　服务端框架
Ribbon:　客户端框架
Hystrix: 服务容错组件
Archaius: 服务配置组件
Servo: Metrics组件
Blitz4j: 日志组件
下图Fig 11展示了基于这些组件构建的一个微服务框架体系，来自recipes-rss。
Fig 11, 基于Netflix开源组件的微服务框架
Netflix的开源框架组件已经在Netflix的大规模分布式微服务环境中经过多年的生产实战验证，正逐步被社区接受为构造微服务框架的标准组件。Pivotal去年推出的Spring Cloud开源产品，主要是基于对Netflix开源组件的进一步封装，方便Spring开发人员构建微服务基础框架。对于一些打算构建微服务框架体系的公司来说，充分利用或参考借鉴Netflix的开源微服务组件(或Spring Cloud)，在此基础上进行必要的企业定制，无疑是通向微服务架构的捷径。
gateway是可以直接做聚合的，阿里在有些场景下就是用gateway做业务聚合和裁剪的，
gateway不作聚合的好处是关注分离和单一职责，gateway作为服务基础设施可以只关注跨横切面的公共逻辑，如路由，安全，监控，日志，容错等，具体的业务聚合动作还是由具有业务背景的的团队独立负责，通常躲在gateway后面。
在Netflix的微服务体系中，
1，Zuul只做跨横切面的功能，如路由，安全认证，容错，限流，日志等
2，Zuul只是一个HTTP网关，聚合或者协议转换(如rpc转换成http)，在Edge Service层做
3，Netflix有集中式的配置服务，客户端采用Archaius组件，定期pull配置服务器上的配置
转自：q.com/cn/articles/basis-frameworkto-implement-micro-service
相关 [服务 基础 框架] 推荐：
- 人月神话的BLOG
上面一篇文章对SpringBoot框架做了一下简单验证，在文中也写到SpringBoot重点还是在单个微服务模块的开发，已经对于微服务接口开放的便捷性上，而对于微服务基础架构和管控治理层面没有太多支持. 对于微服务基础框架可以看作是微服务治理架构的核心内容，包括了对微服务模块的全生命周期管理能力，这个能力包括了微服务网关APP，DevOps，Docker和云集成，安全，负载均衡，服务注册和发现等诸多能力.
- 互联网 - ITeye博客
实施微服务，我们需要哪些基础框架. 作者
杨波 发布于 日 |. 微服务(MicroServices)架构是当前互联网业界的一个技术热点，圈里有不少同行朋友当前有计划在各自公司开展微服务化体系建设，他们都有相同的疑问：一个微服务架构有哪些技术关注点(technical concerns).
- 程序猿DD
最近一段时间不论互联网还是传统行业，凡是涉及信息技术范畴的圈子几乎都在讨论
微服务架构. 近期也看到各大技术社区开始组织一些沙龙和论坛来分享Spring Cloud的相关实施经验，这对于最近正在整理Spring Cloud相关套件内容与实例应用的我而言，还是有不少激励的. 目前，Spring Cloud在国内的知名度并不高，在前阵子的求职过程中，与一些互联网公司的架构师、技术VP或者CTO在交流时，有些甚至还不知道该项目的存在.
- CSDN博客推荐文章
1.在java开发领域，Spring相对于EJB来说是一种轻量级的，非侵入性的Java开发框架，曾经有两本很畅销的书《Expert one-on-one J2EE Design and Development》和《Expert one-on-one J2EEdevelopment without EJB》是java高手进阶必看的宝典，Spring就是从这两本书的理论发展起来的.
- 人月神话的BLOG
Dubbo 是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和
Spring框架无缝集成. 它最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）. 从服务模型的角度来看，Dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方（Provider）和服务消费方（Consumer）两个角色.
- idea's blog
C10K 问题提出的时候, 正是 2001 年, 到如今 12 年后的 2013 年, C10K 已经不是问题了, 任何一个普通的程序员, 都能利用手边的语言和库, 轻松地写出 C10K 的服务器. 这既得益于软件的进步, 也得益于硬件性能的提高.. 现在, 该是考虑
C1000K, 也就是百万连接的问题的时候了.
- 开源软件 - ITeye博客
Undertow是一个Web服务器，那么它就需要具备的现代Web服务器的基本特性，比如Servlet,JSP,文件服务器，代理服务器，安全认证等. undertow目前已经实现了绝大多数功能，并且因为wildfly通过了JavaEE7 TCK认证，所以可以说Undertow是一个通过Servlet 3.1认证的Web服务器和容器.
- ITeye博客
我们从名字上就能看出这是一个NIO思想为基础的IO框架，X是指这个框架可以有多种实现，我们可以从代码库 /xnio 中发现一个项目xnio-native，里面有用C实现的nio层，就能体会到这个X的含义，可以直接基于操作系统C库. 目前在Xnio中默认的实现是nio-impl，也就是JDK的NIO.
- rockmaple - BlueDavy之技术blog
我们的服务框架已经持续做了三年了，在厂内广泛的使用，目前部署在服务框架上的服务为2k+，每天经过服务框架的服务执行次数为120亿+，摸高到150亿+，三年的发展并非一帆风顺，由于经验的原因，还是摔了不少跤的，在这篇blog中，来给大家分享下，希望能够给要做服务框架或服务化的同学带来一些帮助，少走一些弯路，不一定要一开始就做成完整的服务框架，但至少先做好铺垫，避免在广泛使用后再来挽救.
- mk - Tim[后端技术]
大型软件系统开发需要模块化，在分布式系统中，模块化通常是将功能分成不同的远程服务（RPC）来实现. 比如可以用Java RMI、Web Service、Facebook开源的Thrift等一些技术. 同样，在一个大型系统中，服务化之后服务的可维护、可管理、可监控以及高可用、负载均衡等因素同服务本身同样重要.
坚持分享优质有趣的原创文章，并保留作者信息和版权声明，任何问题请联系：@。