⑴ 微服务有哪些设计原则
微服务应用4个设计原则：
作为一个原则来讲本来应该是个“无状态通信原则”，在这里我们直接推荐一个实践优选的Restful 通信风格 ，因为他有很多好处：
无状态协议HTTP，具备先天优势，扩展能力很强。例如需要安全加密是，有现成的成熟方案HTTPS可用。
JSON 报文序列化，轻量简单，人与机器均可读，学习成本低，搜索引擎友好。
语言无关，各大热门语言都提供成熟的Restful API框架，相对其他的一些RPC框架生态更完善。
当然在有些特殊业务场景下，也需要采用其他的RPC框架，如thrift、avro-rpc、grpc。但绝大多数情况下Restful就足够用了。
⑵ 微服务和前端的关系
微服务是后端架构，前端如vue框架使用微服务和其他语言类似，分为前端团队和后端开发相互开发对接即可。
推荐一个开源项目。采用vue3作为前端框架。
MateCloud 基于Spring Cloud Alibaba推出的微服务快速开发平台，集成Nacos 2.0.3、Sentinel 1.8.2、Jetcache等诸多中间件。前端采用Vue3.2.4、Vite 2.5.1、Ant-Design-Vue 2.2.6、TypeScript的大型中后台解决方案。 其中前端4.0.8-M2版本正在发布，实现了系统管理的基础功能，主要包括菜单管理、用户管理、角色管理、部门管理、日志管理、客户端管理等功能。正持续更新中，欢迎体验。
网络搜索MateCloud即可。
⑶ Kubernetes的部署策略，你常用哪种
确定哪种Kubernetes部署方法最适合不断的推出，而不会影响用户的更新。当今开发云原生应用的最大挑战之一是加快部署的速度。通过微服务方法，开发人员已经开始使用并设计完全模块化的应用，允许多个团队同时编写和部署更改到应用去。
更短和更频繁的部署提供了以下优势：
但随着更频繁的发布，对应用可靠性或客户体验产生负面影响的可能性也会增加。这就是为什么DevOps团队必须开发流程和管理部署策略，以最大限度地降低产品和客户风险的原因。
以下，一起讨论Kubernetes的部署策略，包括滚动部署和更高级的方法，如金丝雀及其变体。
根据你的目标，可以利用几种不同类型的部署策略。例如，可能需要将更改推广到特定环境以进行更多测试，或者是用户/客户的子集，或者你可能需要在创建“一般可用”功能之前进行一些用户测试。
滚动部署是Kubernetes的标准默认部署。它逐个缓慢地工作，使用新版本的pod替换以前版本的应用的pod，而不会导致任何集群停机。
在开始缩小旧容器之前，滚动更新会通过准备探针等待新的pod就绪。如果出现问题，可以中止滚动更新或部署，而无需关闭整个集群。在此类部署的YAML定义文件中，新镜像将替换旧镜像。
通过调整清单文件中的参数，可以进一步细化滚动更新：
在这种非常简单的部署中，所有旧的pod都被一次性杀死，并且用新的pod一次全部替换。
这个清单看起来像这样：
在蓝/绿部署策略（有时称为红/黑）中，旧版本的应用（绿色）和新版本（蓝色）同时部署。当部署这两个用户时，用户只能访问绿色，而蓝色可供QA团队在单独的服务上进行测试自动化或通过直接端口转发。
在测试新版本并签署发布后，该服务将切换为蓝色版本，旧版绿色版本将按比例缩小：
金丝雀部署有点像蓝/绿部署，但更受控制并使用更“ 渐进式交付 ”的分阶段方法。有许多策略属于金丝雀的保护范围，包括灰度发布或A/B测试。
当你想要测试一些新功能时，通常在应用程序的后端使用金丝雀。传统上，你可能拥有两个几乎完全相同的服务器：一个用于所有用户，另一个用新功能推送到一部分用户然后进行比较。如果未报告任何错误，则新版本可逐渐推广到基础架构的其余部分。
虽然可以通过替换旧的和新的pod来使用Kubernetes资源来完成此策略，但使用像Istio这样的服务网格实现此策略会更方便，更容易。
例如，你可以在Git中检查两个不同的清单：GA标记为0.1.0，金丝雀标记为0.2.0。通过更改Istio虚拟网关清单中的权重，可以管理这两个部署的流量百分比。
管理金丝雀部署的一种简单有效的方法是使用Weaveworks Flagger。
使用Flagger，金丝雀部署的推广是自动化的。它使用Istio或App Mesh来路由和转移流量，使用Prometheus指标进行金丝雀分析。金丝雀分析还可以通过webhook进行扩展，以运行验收测试，负载测试或任何其他类型的自定义验证。
Flagger采用Kubernetes部署和可选的水平pod自动缩放器（HPA）来创建一系列对象（Kubernetes部署，ClusterIP服务和Istio或App Mesh虚拟服务），以推动金丝雀分析和推广。
通过实施控制回路，Flagger逐渐将流量转移到金丝雀，同时测量关键性能指标，如HTTP请求成功率，请求平均持续时间和pod 健康 状况。根据对KPI的分析，金丝雀被提升或中止，分析结果发布给Slack。
灰度部署是金丝雀的另一种变体（顺便提一下，也可以由Flagger处理）。灰度部署和金丝雀之间的区别在于，灰度部署处理前端而不是后端的功能。
灰度部署的另一个名称是A/B测试。你可以将其发布给少数用户，而不是为所有用户启动新功能。用户通常不知道他们被用作新功能的测试人员，因此称为“灰度”部署。
通过使用功能切换和其他工具，你可以监控用户与新功能的交互方式，以及是否正在转换用户，或者他们是否发现新的UI令人困惑以及其他类型的指标。
除了加权路由，Flagger还可以根据HTTP匹配条件将流量路由到金丝雀。在A/B测试场景中，你将使用HTTP标头或Cookie来定位用户的特定部分。这对需要会话关联的前端应用特别有用。
⑷ 如何快速搭建一个微服务架构
什么是微服务？
微服务(Microservices Architecture)是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。
微服务的概念源于2014年3月Martin Fowler所写的文章“Microservices” martinfowler.com/articles/mi…
单体架构(Monolithic Architecture )
企业级的应用一般都会面临各种各样的业务需求，而常见的方式是把大量功能堆积到同一个单体架构中去。比如：常见的ERP、CRM等系统都以单体架构的方式运行，同时由于提供了大量的业务功能，随着功能的升级，整个研发、发布、定位问题，扩展，升级这样一个“怪物”系统会变得越来越困难。
这种架构模式就是把应用整体打包部署，具体的样式依赖本身应用采用的语言，如果采用java语言，自然你会打包成war包，部署在Tomcat或者Jetty这样的应用服务器上，如果你使用spring boot还可以打包成jar包部署。其他还有Rails和Node.js应用以目录层次的形式打包
上图：单体架构
大部分企业通过SOA来解决上述问题，SOA的思路是把应用中相近的功能聚合到一起，以服务的形式提供出去。因此基于SOA架构的应用可以理解为一批服务的组合。SOA带来的问题是，引入了大量的服务、消息格式定义和规范。
多数情况下，SOA的服务直接相互独立，但是部署在同一个运行环境中（类似于一个Tomcat实例下，运行了很多web应用）。和单体架构类似，随着业务功能的增多SOA的服务会变得越来越复杂，本质上看没有因为使用SOA而变的更好。图1，是一个包含多种服务的在线零售网站，所有的服务部署在一个运行环境中，是一个典型的单体架构。
单体架构的应用一般有以下特点：
微服务架构（Microservices Architecture）
微服务架构的核心思想是，一个应用是由多个小的、相互独立的、微服务组成，这些服务运行在自己的进程中，开发和发布都没有依赖。不同服务通过一些轻量级交互机制来通信，例如 RPC、HTTP 等，服务可独立扩展伸缩，每个服务定义了明确的边界，不同的服务甚至可以采用不同的编程语言来实现，由独立的团队来维护。简单的来说，一个系统的不同模块转变成不同的服务！而且服务可以使用不同的技术加以实现！
上图：微服务架构
微服务设计
那我们在微服务中应该怎样设计呢。以下是微服务的设计指南：
微服务消息
在单体架构中，不同功能之间通信通过方法调用，或者跨语言通信。SOA降低了这种语言直接的耦合度，采用基于SOAP协议的web服务。这种web服务的功能和消息体定义都十分复杂，微服务需要更轻量的机制。
同步消息 REST
同步消息就是客户端需要保持等待，直到服务器返回应答。REST是微服务中默认的同步消息方式，它提供了基于HTTP协议和资源API风格的简单消息格式，多数微服务都采用这种方式（每个功能代表了一个资源和对应的操作）
异步消息 – AMQP, STOMP, MQTT
异步消息就是客户端不需要一直等待服务应答，有应到后会得到通知。某些微服务需要用到异步消息，一般采用AMQP, STOMP, MQTT 这三种通讯协议
消息格式 – JSON, XML, Thrift, ProtoBuf, Avro
消息格式是微服务中另外一个很重要的因素。SOA的web服务一般采用文本消息，基于复杂的消息格式（SOAP）和消息定义（xsd）。微服务采用简单的文本协议JSON和XML，基于HTTP的资源API风格。如果需要二进制，通过用到Thrift, ProtoBuf, Avro。
服务约定 – 定义接口 – Swagger, RAML, Thrift IDL
如果把功能实现为服务，并发布，需要定义一套约定。单体架构中，SOA采用WSDL，WSDL过于复杂并且和SOAP紧耦合，不适合微服务。
REST设计的微服务，通常采用Swagger和RAML定义约定。
对于不是基于REST设计的微服务，比如Thrift，通常采用IDL（Interface Definition Languages），比如Thrift IDL。
微服务集成 (服务间通信)
大部分微服务基于RPC、HTTP、JSON这样的标准协议，集成不同标准和格式变的不再重要。另外一个选择是采用轻量级的消息总线或者网关，有路由功能，没有复杂的业务逻辑。下面就介绍几种常见的架构方式。
点对点方式
点对点方式中，服务之间直接用。每个微服务都开放REST API，并且调用其它微服务的接口。
上图：通过点对点方式通信
很明显，在比较简单的微服务应用场景下，这种方式还可行，随着应用复杂度的提升，会变得越来越不可维护。这点有些类似SOA的ESB，尽量不采用点对点的集成方式。
API-网关方式
API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能个。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。
上图：通过API-网关暴露微服务
所有的业务接口通过API网关暴露，是所有客户端接口的唯一入口。微服务之间的通信也通过API网关。
采用网关方式有如下优势：
目前，API网关方式应该是微服务架构中应用最广泛的设计模式。
消息代理方式
微服务也可以集成在异步的场景下，通过队列和订阅主题，实现消息的发布和订阅。一个微服务可以是消息的发布者，把消息通过异步的方式发送到队列或者订阅主题下。作为消费者的微服务可以从队列或者主题共获取消息。通过消息中间件把服务之间的直接调用解耦。
上图：异步通信方式
通常异步的生产者/消费者模式，通过AMQP, STOMP, MQTT 等异步消息通讯协议规范。
数据的去中心化
单体架构中，不同功能的服务模块都把数据存储在某个中心数据库中。
每个微服务有自己私有的数据库，其它微服务不能直接访问。单体架构，用一个数据库存储所有数据
微服务方式，多个服务之间的设计相互独立，数据也应该相互独立（比如，某个微服务的数据库结构定义方式改变，可能会中断其它服务）。因此，每个微服务都应该有自己的数据库。
每个微服务有自己私有的数据库，其它微服务不能直接访问。每个微服务有自己私有的数据库，其它微服务不能直接访问。
数据去中心话的核心要点：
数据的去中心化，进一步降低了微服务之间的耦合度，不同服务可以采用不同的数据库技术（SQL、NoSQL等）。在复杂的业务场景下，如果包含多个微服务，通常在客户端或者中间层（网关）处理。
微服务架构的优点：
微服务架构的缺点：
微服务的一些想法在实践上是好的，但当整体实现时也会呈现出其复杂性。
关于微服务架构的取舍
⑸ 微服务架构下，进行前后端分离，前端怎么写
分离后的前端，不再是一个简单的HTML文件，已经是一个独立的应用系统。除了要考虑页面的数据渲染展示，还要用工程化的思想来考虑前端的架构，前后端的交互和数据安全等事情。
RESTful接口交互
前后端分离之后，更多的是采用RESTful风格的接口与后端进行数据交互。
REST是“呈现状态转移（REpresentational State Transfer）”的缩写，一种API的架构风格，在客户端和服务端之间通过呈现状态的转移来驱动应用状态的演进。
在 REST 样式的 Web 服务中，每个资源都有一个地址。资源本身都是方法调用的目标，方法列表对所有资源都是一样的。这些方法都是标准方法，包括 HTTP GET、POST、PUT、DELETE，还可能包括 HEADER 和 OPTIONS。
RESTful的API设计，使得后端通过接口向前端传递数据，数据的格式通常是JSON这种通用的格式。对前端来说，只要后端返回过来的是RESTful的数据就行，不管后端是用Java写，还是用python或PHP，拜托对后端的依赖，做到前端系统的独立。
工程化构建
Nodejs不止可以用来做前端服务器，在开发阶段，它也能发挥很大的作用。
前端生态的发展，是围绕着Nodejs进行的。用npm来管理项目依赖，可以很好的维护和运行在Nodejs环境上。
打包工具grunt、gulp、webpack和rollup等，都是运行在nodejs上，再结合语法编译、打包部署等插件，将应用输入成一个完整的应用。
如果你使用了Angular、React或Vue框架，或者你使用浏览器暂时还不兼容的ES6语法，还需要在应用打包前用babel将语法编译成浏览器可识别的ES5的语法。
SPA
SPA是单页Web应用（single page web application，SPA）的简写，就是只有一张Web页面的应用，是加载单个HTML 页面并在用户与应用程序交互时动态更新该页面的Web应用程序。
像Angular、React或Vue就是为了SPA而设计的，结合前端路由库（react-router、vue-router）和状态热存储（rex、vuex）等，可以开发出一个媲美Native APP的Web APP，用户体验得到了很大的提升。
当然，SPA也不是完美的，也不是适合所有的web应用，需要结合项目和场景来选择。
SPA有如下缺点：
初次加载耗时增加。可以通过代码拆分、懒加载来提升性能，减少初次加载耗时。
SEO不友好，现在可以通过Prerender或Server render来解决一部分。
页面的前进和后端需要开发者自己写，不过现在一些路由库已经帮助我们基本解决了。
对开发者要求高，由于做SPA需要了解一整套技术栈，所以，要考虑后期是否有合适的人选进行维护。
⑹ 如何设计实现真正的响应式微服务系统
一、清晰轻量的产品逻辑
奥卡姆剃须刀法则同样在产品架构设计中适用，越简单的架构越有利于产品的生长。清晰轻量的产品逻辑，会减少用户的负担感，从而提高交互上的效率和愉悦感。
分析Material Design，会发现Google归纳了两类复杂内容信息的层级关系，分别是Card和Tile（List
以及其他相似定义属于同类的内容信息层级），其他定义多用于UI结构及细节。其中，Google定义Card是一种多功能信息的聚合入口，信息层级应较
高，体现在Z轴应高于其他信息，视觉上有阴影表现并加以圆角处理。而tile（或同类信息列表）则是（同类或相关）信息的模块展现，信息层级应较低，体现
在Z轴应略低于其他信息，视觉上应无阴影表现不加圆角处理。其结果是从视觉层面让产品对象更高效、更简单，同时也更具物理世界的“真实感”。
最近接手的项目是Gekec.com的全站改版。Gekec（革客）是Geek和Maker交集，喜欢革新，喜欢技术范儿、新潮的科技消费品，喜欢
自己动手创造产品，Gekec.com也就是这类人的聚集地，整个产品囊括电商、资讯（或h5宣传）、拆机、以及社区讨论等各种功能，改版前逻辑复杂，功
能繁多。改版开始之初，笔者了解到革客群体时，便认为理性加浓重Geek味道的Google风格或许是最适合Gekec.com的视觉体系，然而复杂的产
品逻辑不能给用户带来高效的交互体验和愉悦的使用感受，视觉上也并不能很好的通过Material
Design推演并且变化，所以梳理出清晰、轻量且方便视觉统一的产品逻辑成为第一任务。
Gekec.com的产品全功能在此并不赘述，Proct Feature全部为达成宜家式的体验式设计，经过梳理可以归纳成三层，首层为体验层（多入口的首页封面）、第二层为货架层（包括商城模块、拆机模块、体验模块）、第三层为详细、操作层；
如上图，轻量的产品结构即可方便设计的推演。例如其中第一层可以通过H5灵活排版做产品全方位体验，第二层与第三层的关系即可利用Material
Card和Tile表现。Card表达了全部信息的聚合和入口，tile则表现同类信息的罗列。从card跳转到最终页应有一种卡片展开的体验。
二、适宜UI推演的响应办法
在产品逻辑清晰简洁的基础上，一套适宜Material Design变化的全尺寸响应办法就成为复杂响应式网页设计的核心内容，响应办法能够直接决定功能模块的响应逻辑以及UI的变化。实际操作中，响应办法的确定主要就是确定栅格和占比。
1）栅格
网页栅格系统是从平面栅格系统中发展而来。对于网页设计来说，栅格系统的使用，不仅可以让网页的信息呈现更加美观易读，更具可用性。而且，对于前端
开发来说，网页将更加的灵活与规范。栅格系统的具体含义以及使用方法在此不再赘述，感兴趣的朋友可以参考淘宝UED的一些文章：
网页栅格系统研究（1）：960的秘密
网页栅格系统研究（2）：蛋糕的切法
网页栅格系统研究（3）：粒度问题
网页栅格系统研究（4）：技术实现
在Gekec.com的项目中，经历产品功能模块的梳理，笔者使用了12栅格系统，目的是能够满足2、3、4、6的页面等分。注：具体栅格系统的建立应因产品和设计所决定，栅格系统并不是万能的，而确定的栅格系统可以为整个响应式设计做规范性参考。
2）占比
A.占比
如上文说，12栅格约束网页的内容区，而网页的内容往往并不占据屏幕的全部宽度，而是在两侧留有间隙，营造空间感。由于屏幕的限制，这种空间感在移动端设备显得更加重要，如图，然而强加固定的margin pixel会使得12栅格占比不定，难以控制设计效果。
所以占比应是12栅格宽度对应屏幕的比值，即：
12栅格宽度X占比=屏幕宽（临界点）
优秀而巧妙的占比确定可以让网页设计呈现在各个主流屏幕上均是100%像素。
这里简单解释一下，若一个200px宽的元素在1200px宽的屏幕上，其占比为16.67%，同样的逻辑，到1024px的屏幕上这个占比
16.67%的元素即占据了170.67px，这样的情况下，某一个物理像素无法占据100%，在完美主义的设计师眼里，是无法接受的事情。而巧妙的占
比，可以让元素在各个主流屏幕占据100%像素，完美展现设计意图。
B.临界点
临界点（breakpoint）是指响应式网页发生布局变化的关键点，如“当屏幕宽度小于480px时加载...样式，当宽度在480px-
600px之间时加载…样式”。响应式网页理论上有无数种尺寸，我们不可能也没有必要为每个尺寸都去做设计，需要做的是选定几个临界点做设计，在两个临界
点之间是延续上一个临界点的布局。
临界点确认总体目的就是为了保证页面在手机（屏幕很小）、平板（屏幕中等）、PC（屏幕大）上加载相应的样式，然而经验较少的设计师往往会苦恼一个
问题，那就是高像素的手机屏幕和低像素的平板屏幕应如何处理。例如设计师会担心1080p的手机加载大屏幕页面，或者720p的平板加载小屏幕页面。
但需要注意的是，响应式网页不同于APP的屏幕适配。网页是沉浸于浏览器的产品，浏览器所启动的屏幕像素才可以被认为是临界点的参考点，为此，笔者
做了一些测试，如下表，可以看出不少1080p手机在浏览器中仅启动360px，而神奇的ipad无论是不是retina屏幕，无论是不是mini，均显
示1024x768px 。
⑺ 微服务架构 如何影响传统的软件架构设计
ThoughtWorks首席咨询师王磊通过一个互联网门户案例为大家解释了微服务架构的概念，以及它如何影响传统的软件架构设计。
一年前，该门户每签一个10万的合同所耗费的成本是3.5天。他们当时的CRM结构是典型的三层架构，整个应用程序由一个40万行的代码库组成，后端有一个主动的数据库。虽然使用三层架构的成本比较小，但随着代码和功能的增加，代码库不断膨胀，修改代码存在的风险很大，整个维护成本也变得越来越高。
每当开发人员提交代码后，所需的数据集成和构建需要50分钟，意味着每天8小时工作时间最多能有9次代码提交。但为了系统的稳定性，持续集成过程中要尽量避免提交代码，因此，整个团队的交付能力受到了限制。此外，从准备部署包到上线需要3天，3天后才能让用户真正用到部署包，才能实现价值。而如果增加新人，要开发新的环境，包括测试和产品环境，培养周期会很长。针对以上难题，ThoughtWorks制定了如何在团队中对系统进行改造从而满足业务需求的策略。
将现有的系统保护起来，把所有开发新功能的优先级都降下来，只需对系统做最紧急的修改，其他和部门进行协商，让团队保持新的精力和时间在重要的业务上。
功能剥离。通过定义新服务，在前端用一些代码的机制让用户逐渐访问新服务，可以达到从原有系统抽出小功能，让客户访问小功能。
数据解耦。对于庞大的系统，因为无法很快将所有系统换掉，所以为了保证系统仍然可用，要启用数据同步机制，让服务里的数据同步到原有数据库。
渐进替换。通过不断地运行以上策略，将原有系统的复杂功能抽离出来用新的方式来做。
目前，每签一个10万的合同所耗费的成本由3.5天变为1天，持续集成构建从50钟降低到18分钟，团队成员从10人降到7人，部署周期由3天降到2小时。
对于每个应用程序，可能有一组小的服务组成，每个服务运行在自己的进程中，服务与服务之间通过轻量级的机制进行交互。那么，如何使用微服务做系统改造呢?
为每个服务建立独立的环境，包括基础设施、持续集成环境、运维、监控、日志聚合、报警。
不断演进的微服务开发模板，发现问题及时修改，让模板更高效。
轻量级的通信协议。
消费者的契约测试，解决随着服务增多带来集成测试效率低的问题。
基础设施自管理，帮助管理自己需要的资源。
⑻ 《微服务设计中文版》pdf下载在线阅读全文，求百度网盘云资源
《微服务设计中文版》网络网盘pdf最新全集下载:
链接: https://pan..com/s/1KYbkPkfUtirjguQnxVpdFA
简介：全面介绍了微服务的建模、集成、测试、部署和监控，通过一个虚构的公司讲解了如何建立微服务架构。主要内容包括认识微服务在保证系统设计与组织目标统一上的重要性，学会把服务集成到已有系统中，采用递增手段拆分单块大型应用，通过持续集成部署微服务。
⑼ 什么是微服务架构主流的微服务如何实现
简单地说，微服务架构就是以业务域或业务功能为边界，将一个大而全的应用拆分为可以独立开发，独立部署，独立测试，独立运行的一组小的应用，并且使用轻量级，通用的机制在这组应用间进行通信。
主流的微服务包括：
1、SpringCloud
Spring Cloud , 来自Spring，具有Spring 社区的强大支撑，还有Netflix强大的后盾与技术输出。Netflix作为一家成功实践微服务架构的互联网公司在几年前就把几乎整个微服务框架栈开源贡献给了社区，这些框架开源的整套服务架构套件是Spring Cloud的核心。
- Eureka:服务注册发现框架；
- Zuul:服务网关；
- Karyon：服务端框架；
- Ribbon：客户端框架；
- Hystrix：服务容错组件；
- Archaius：服务配置组件；
- Servo：Metrics组件；
- Blitz4j：日志组件；
2、Dubbo
Dobbo是一个分布式服务框架，是阿里开放的微服务化治理框架，致力于提高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。其核心部分(官网)
- 远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式；
- 集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持；
- 自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。
Dubbo 也是采用全 Spring 配置方式，透明化接入应用，对应用没有任何 API 侵入，只需用 Spring 加载 Dubbo的配置即可，Dubbo 基于 Spring 的 Schema 扩展进行加载。当然也支持官方不推荐的 API 调用方式。
3、lstio
lstio 作为用于微服务聚合层管理的新锐项目，是Google、IBM、Lyft（海外共享出行公司、Uber劲敌），首个共同联合开源的项目，提供了统一的连接，安全，管理和监控微服务的方案。
目前首个测试版是针对Kubernetes环境的，社区宣称在未来几个月内会为虚拟机和Cloud Foundry 等其他环境增加支持。lstio将 流量管理添加到微服务中，并为增值功能（如安全性、监控、路由、连接管理和策略）创造了基础。
- HTTP、gRPC 和 TCP 网络流量自动负载均衡；
- 提供了丰富的路由规则，实现细颗粒度的网络流量行为控制；
- 流量加密、服务件认证，以及强身份声明；
- 全范围（Fleet-wide）的策略执行；
- 深度遥测和报告。