Chinaunix
标题: 【话题讨论】理解微服务架构，实践云原生应用！ [打印本页]
作者: gaokeke123 时间: 2019-07-30 14:17
标题: 【话题讨论】理解微服务架构，实践云原生应用！
话题背景：
微服务架构是一项在云中部署应用和服务的新技术。大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。
微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程的架构。
讨论内容：
1.微服务的定义？微服务需要“微”到什么程度？
2.微服务的重大优势是什么？它是未来吗？
3.微服务在实践过程中最大的难点是什么？
4.微服务、容器技术两者的关系？两者结合带来什么新趋势？
5.怎么处理微服务与外部相连，以及获取数据？
6.微服务与容器结合会发展出新趋势--Cloud Native，什么是Cloud Native？（可选答）
活动时间：2019年7月30日-2019年8月18日
奖项设置：
一等奖1名：2019中国系统架构师大会 门票1张
二等奖3名：中国系统架构师大会（SACC）十周年纪念T恤一件
三等奖若干：50个 IT168文库金币
备注：CU论坛与ITpub话题讨论答案同步筛选，希望大家积极参与哦。
2019年10月31日~11月2日，由 IT168 旗下 ITPUB 企业社区平台主办的第十一届中国系统架构师大会（SACC2019)将在北京隆重召开。自2009年举办以来，大会云集了国内 CTO、研发总监、高级系统架构师、开发工程师和IT经理等技术人群，与会规模超千人。
本届大会继续沿用四大主线并行的演讲模式，设置业务系统架构设计、大数据平台架构设计、数字化转型实践和开源架构设计四大主线，共1个主会场，20个技术专场，100+来自互联网、金融、制造业、电商等领域嘉宾，将为广大参会者提供一场最具价值的技术交流盛会。
作者: gaokeke123 时间: 2019-07-31 13:40
欢迎大家踊跃参与话题讨论哦~前排占楼
作者: tomorrowcome 时间: 2019-07-31 13:51
1.微服务的定义？微服务需要“微”到什么程度？
（1）每一个微服务是一个独立的自治系统，不依赖外部组件，能够独立运行；
（2）对外只能通过API提供服务或者获取服务；
（3）粒度足够小。
微服务的粒度与团队组织方式是相关，与业务功能的构成相关，与数据相关。
在业务功能方面，尽量做到一个模块中的业务高度类聚集，和外部模块做到松耦合，获取灵活性；在数据方面，一个微服务尽量不要和外部频繁的交互数据，大量的API交互对性能和可靠性都有影响。
2.微服务的重大优势是什么？它是未来吗？
微服务，是一种去中心化的架构。一般和更细粒度的容器配合使用，天生自带很强的共生性。
从早期的集中式架构，到分布式架构，再到现在更细粒度化的微服务，其实一直朝着去中心化的趋势发展，具备更强的灵活性以及更适合云的特点。
微服务是未来一种非常主要的、应用广泛的架构，但并不一定说它会统治一切。微服务化更适合无状态、高迭代的业务场景。
3.微服务在实践过程中最大的难点是什么？
微服务在实践过程中，最大的问题是团队之间的运作和管理。康威定律提到，有什么样的团队组织方式，就有什么样的业务架构。业务架构，是和团队组织架构相匹配的，当我们把一个大的系统，拆分成小的服务时，团队会随之变化。团队成员需要适应微服务的开发模式，微服务对每个程序员有着更高的要求。
微服务实践的难点不在于没法拆分，难点在于很多人的思想停留在以前的架构思想下。建议逐步改造、持续迭代地改造架构。新业务、新团队可以独立地采用微服务化运作。
4.微服务、容器技术两者的关系？两者结合带来什么新趋势？
微服务是一种架构思想，而容器，或者说以Docker为代表的容器技术，是一种运行载体。容器天生适合细粒度的微服务，容器管理和分发需要Docker的支持。两者结合，就是去中心化思想的实践。
伴随互联网与云计算的发展，什么样的架构或者产品研发模式是适合云模式的？是传统的集中式架构吗？分布式架构吗？现在创业型公司的特点：完全基于云端，轻资产，小团队作战，快速的产品迭代。为了适应这些特点，必须基于云的原生特点去设计应用架构，所以微服务和容器发展的新趋势，就是去实践Cloud Native。
5.怎么处理微服务与外部相连，以及获取数据？
微服务是通过API对外提供服务，本身是一个独立的自治系统，所以不存在需要与很多数据中心相互连接的情况；如果需要通讯，直接适用公网连接就可以。
换句话说，微服务和微服务之间的数据通讯是通过API调用的。没有所谓的内部的进程间、共享信号、共享内存队列的模式。一个微服务对外提供的服务一定是封装好的、接口式的。
6.微服务与容器结合会发展出新趋势--Cloud Native，什么是Cloud Native？
在云时代，全部应用都基于云去构建，并不适合套用传统的研发模式。Cloud Native是指云原生的应用架构，是专门针对云的架构。它主要包括三个部分，一种全新的架构思想（微服务），一种业务运行管理模式，以及一种团队组织管理方式。关乎DevOps、小团队、敏捷开发。Cloud Native既不是一个新的技术，也不是一套新的架构，而是产品研发、运营的全新模式。它是在云的生态场景生长出来的，和云的关系是一种鱼和水的关系。
作者: post200 时间: 2019-08-01 11:10
微服务的定义？微服务需要“微”到什么程度？
就是将单一程序开发成一个微服务，每个微服务运行在自己的进程中，
并使用轻 量级机制通信，通常是 HTTP RESTFUL API。这些服务围绕业务能力来划分构建的，并通过
完全自动化部署机制来 独立部署。 这些服务可以使用不同的编程语言，以及不同数据存储技术，以保
证最低限度的集中式管理。
微服务的重大优势是什么？它是未来吗？
优点提升开发交流，每个服务足够内聚，足够小，代码容易理解；服务独立测试、部署、升级、发布；按需定制的DFX，资源利用率，每个服务可以各自进行x扩展和z扩展，而且，每个服务可以根据自己的需要部署到合适的硬件服务器上；每个服务按需要选择HA的模式，选择接受服务的实例个数；容易扩大开发团队，可以针对每个服务（service）组件开发团队；提高容错性（fault isolation），一个服务的内存泄露并不会让整个系统瘫痪；新技术的应用，系统不会被长期限制在某个技术栈上
作者: mysdirma 时间: 2019-08-01 14:58
微服务在实践过程中最大的难点是什么？
微服务在实践过程中，最大的问题是团队之间的运作和管理的问题.因为微服务，对每个程序员的要求是比较高的：每个程序员的权责会更明显，需要标准化接口、书写规范文档，而且一般需要有DevOps的工作。
作者: mysdirma 时间: 2019-08-02 10:52
怎么处理微服务与外部相连，以及获取数据？
在设计时就需要考虑到微服务有哪些数据需求（见问题一的第二小问）：微服务都是通过API对外提供服务，本身是一个独立的自治系统，所以不存在需要与很多数据中心相互连接的情况；如果需要通讯，直接适用公网连接就可以了。
作者: lcc 时间: 2019-08-02 14:04
微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程
作者: regatta 时间: 2019-08-02 15:44
微服务的重大优势是什么？它是未来吗？
每个服务都比较简单，只关注于一个业务功能。
微服务架构方式是松耦合的，可以提供更高的灵活性。
微服务可通过最佳及最合适的不同的编程语言与工具进行开发，能够做到有的放矢地解决针对性问题。
每个微服务可由不同团队独立开发，互不影响，加快推出市场的速度。
微服务架构是持续交付(CD)的巨大推动力，允许在频繁发布不同服务的同时保持系统其他部分的可用性和稳定性。
作者: suliver 时间: 2019-08-02 16:35
微服务架构的缺点有啥呀？
作者: chunian 时间: 2019-08-02 16:36
运维开销及成本增加：整体应用可能只需部署至一小片应用服务区集群，而微服务架构可能变成需要构建/测试/部署/运行数十个独立的服务，并可能需要支持多种语言和环境。这导致一个整体式系统如果由20个微服务组成，可能需要40~60个进程。
必须有坚实的DevOps开发运维一体化技能：开发人员需要熟知运维与投产环境，开发人员也需要掌握必要的数据存储技术如NoSQL，具有较强DevOps技能的人员比较稀缺，会带来招聘人才方面的挑战。
隐式接口及接口匹配问题：把系统分为多个协作组件后会产生新的接口，这意味着简单的交叉变化可能需要改变许多组件，并需协调一起发布。在实际环境中，一个新品发布可能被迫同时发布大量服务，由于集成点的大量增加，微服务架构会有更高的发布风险。
代码重复：某些底层功能需要被多个服务所用，为了避免将“同步耦合引入到系统中”，有时需要向不同服务添加一些代码，这就会导致代码重复。
分布式系统的复杂性：作为一种分布式系统，微服务引入了复杂性和其他若干问题，例如网络延迟、容错性、消息序列化、不可靠的网络、异步机制、版本化、差异化的工作负载等，开发人员需要考虑以上的分布式系统问题。
异步机制：微服务往往使用异步编程、消息与并行机制，如果应用存在跨微服务的事务性处理，其实现机制会变得复杂化。
可测性的挑战：在动态环境下服务间的交互会产生非常微妙的行为，难以可视化及全面测试。经典微服务往往不太重视测试，更多的是通过监控发现生产环境的异常，进而快速回滚或采取其他必要的行动。但对于特别在意风险规避监管或投产环境错误会产生显著影响的场景下需要特别注意。
希望对你有所帮助
作者: post200 时间: 2019-08-02 16:59
微服务与容器结合会发展出新趋势--Cloud Native，什么是Cloud Native？
CloudNative 最大的思维转变当属 Stateless Infrastructure（无状态基础设施）。这样可以大幅度保障应用的可用性和水平扩展能力，当传统的计算资源和存储资源已经通过云计算技术达到了海量。应用的瓶颈就来自于应用架构和基础设施结构。如果还在思考基础设施的状态如何监控和保存，就又进入了老的思维模式，只不过换了新的工具而已。
作者: aloki 时间: 2019-08-04 00:01
1.微服务的定义？微服务需要“微”到什么程度？
微服务 (Microservices) 是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通信。
尽管“微服务”早已成为一种极具人气的架构类型，但这一名称却并不能准确反映服务的实际规模——换言之，“微”服务并不一定微，具体规模可谓多种多样。规模较小的团队则由六人组成，负责支持六项服务。
2.微服务的重大优势是什么？它是未来吗？
·提升开发交流，每个服务足够内聚，足够小，代码容易理解；
·服务独立测试、部署、升级、发布；
·按需定制的DFX，资源利用率，每个服务可以各自进行x扩展和z扩展，而且，每个服务可以根据自己的需要部署到合适的硬件服务器上；
·每个服务按需要选择HA的模式，选择接受服务的实例个数；
·容易扩大开发团队，可以针对每个服务（service）组件开发团队；
·提高容错性（fault isolation），一个服务的内存泄露并不会让整个系统瘫痪；
·新技术的应用，系统不会被长期限制在某个技术栈上；
微服务架构有很多吸引人的地方，但在拥抱微服务之前，也需要认清它所带来的挑战。
3.微服务在实践过程中最大的难点是什么？
·开发人员要处理分布式系统的复杂性；
·服务之间的分布式通信问题；
·服务的注册与发现问题；
·服务之间的分布式事务问题；
·数据隔离再来的报表处理问题；
·服务之间的分布式一致性问题；
·服务管理的复杂性，服务的编排；
·不同服务实例的管理。
4.微服务、容器技术两者的关系？两者结合带来什么新趋势？
虽然使用一般的服务器虚拟化技术就能应用于微服务的管理，但容器技术 (Container Technology) 如 Docker 会更加地适合发展微服务的运算资源管理技术。Docker
作为一种开源的应用容器引擎，帮助开发者将他们的应用以及依赖打包到一个可移植的容器中，便于应用的部署和扩展。而随之产生的微容器概念和微服务正好相辅相成，通过Docker 封装的应用可以轻松运行在以扩容能力见长的云计算平台上。数人云作为专业的数据中心管理系统，提供了基于 Mesos 和Docker 技术的企业级容器云生产环境，通过一键部署、横向扩展、持续集成等特性，助力微服务架构在企业应用环境的实践。
5.怎么处理微服务与外部相连，以及获取数据？
单个微服务在上线的时候，会向服务探索中心（如：Consul）注册自己的 IP 位置、服务内容，如此一来就不需要向每个微服务表明自己的 IP 位置，也就不用替每个微服务单独设置。当服务需要调用另一个服务的时候，会去询问服务探索中心该服务的 IP 位置为何，得到位置后即可直接向目标服务调用。
这么做的用意是可以统一集中所有服务的位置，就不会分散于每个微服务中，且服务探索中心可以每隔一段时间就向微服务进行健康检查（如透过：TCP 调用、HTTP 调用、Ping），倘若该服务在时间内没有回应，则将其从服务中心移除，避免其他微服务对一个无回应的服务进行调用。
作者: laputa73 时间: 2019-08-05 13:39
本帖最后由 laputa73 于 2019-08-05 13:43 编辑
这个话题比较热门，
1.微服务的定义？微服务需要“微”到什么程度？
这个问题其实是微服务最核心的问题。
微服务其实并没有明确的定义，相对于单体应用，微服务有明显的差异。
但是相对于分布式的多服务体系，微服务的差异体现在哪里？
传统的SOA同样有服务注册、服务网关、服务路由。
微服务虽然可以脱离网关，只通过注册中心寻址，p2p调用，但是最佳的推荐应用方式仍然是通过网关。
所以，微服务更多是一个理念，而不是一个明确的概念。
微服务是不是越微越好？
答案我认为是否定的。
一个上百个api的系统，通过上百个服务来实现，会给运维来来无穷无尽的烦恼。
相反，类似的功能，聚合到一个服务中集中实现，效率更高。总体分为10来个服务可能就足够，
从单体到分布式集群是一个质的变化，但是从分布式到微服务，只是一个量的调整。
2.微服务的重大优势是什么？它是未来吗？
微服务最大的优势是统一了分布式RPC接口，让进程间通信和服务通信成为了统一模式，
只要分布式调用的需求存在，微服务的思想就在。
相对于传统的单体系统，微服务主要的革命是去掉了session，强制api无状态.
3.微服务在实践过程中最大的难点是什么？
粒度拆分的决策。
服务之间数据一致性问题。
运维问题。
多语言问题。
还有一个内外划分的问题，传统的系统功能明确，内部系统走rpc,外部系统通过soa相互通信。现在都统一成微服务了。
谁是内，谁是外？系统边界在哪？服务中心需要建一套，还是多套？
4.微服务、容器技术两者的关系？两者结合带来什么新趋势？
没有容器(docker)，也会有微服务。各种语言都有自己的web/rest app容器。
例如java的spring boot, python的flask.
但是有了docker容器，微服务的隔离更彻底，部署更清晰。
而且，依托k8s的容器调度，可以实现更高层次的微服务治理。
5.怎么处理微服务与外部相连，以及获取数据？
微服务的数据同步是个很复杂的问题。
理论上微服务之间只存在api调用. 但是每个微服务自己搞一个数据库是不现实的。
所以系统中需要有一部分服务，单独处理数据。成为数据服务。
然后通过这些服务，暴露数据操作接口。
对于这些数据服务，可以直接操作数据库，本质上和传统的服务/DAO这些没有太大差别。
微服务区分内外，和外部服务交互一定要过网关。
如果从外部获取数据，量小的走api,量大的可能走专用通道，例如文件，队列。
6.微服务与容器结合会发展出新趋势--Cloud Native，什么是Cloud Native？（可选答）
云原生的概念是相对于直接把老系统迁移到容器、虚机部署而言的。
实际上，只要用上了docker+微服务这一套体系。支持了集群扩缩容，自然就是云原生了。
多说一句，目前的的微服务架构，spring cloud还是主流
但是和云原生结合，service mesh(istio)才是更纯粹的微服务架构。
作者: oswald 时间: 2019-08-05 16:32
请问各位大佬，什么时候应该使用微服务？
作者: nt1979 时间: 2019-08-05 17:22
哪些应用可以从微服务收益？
作者: mysdirma 时间: 2019-08-05 17:43
回复 16# nt1979
记录型系统(System of Record)将从微服务方法中获益最多。例如可将大型应用按相对独立的业务功能分解成若干个微服务实现。
交互型系统(System of Engagement)也将受益于微服务方法，例如渠道应用可以应用“后端服务前端”的模式实现。
分析型系统(System of Insight)则可能对微服务受益不多。其他架构模式如管道及过滤模式可能更适用于分析型系统。
作者: renxiao2003 时间: 2019-08-06 11:27
1.微服务的定义？微服务需要“微”到什么程度？
将单一应用划分为一组小的服务，服务之间互相协调、配合，为用户提供最终价值的架构体系。而每个服务运行在独立的进程中，服务之间采用轻量级通信（通常是基于HTTP协议的Rest API），并且每个服务都承载着独立的业务单元责任，能够被独立的部署和发布。
微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称，微服务是需要与业务能力相匹配，这种说法完全正确。不幸的是，仍然意味着，如果能力模型粒度的设计是错误的，那么，我们就必须付出很多代价。如果你阅读了Fowler的整篇文章，你会发现，其中的指导建议是非常实用的。在决定将所有组件组合到一起时，开发人员需要非常确信这些组件都会有所改变，并且规模也会发生变化。服务粒度越粗，就越难以符合规定原则。服务粒度越细，就越能够灵活地降低变化和负载所带来的影响。然而，利弊之间的权衡过程是非常复杂的，我们要在配置和资金模型的基础上考虑到基础设施的成本问题。
微服务到底应该微到什么程度，根据个人观点，不能太微，也不能不微。太微了容易造成资源的浪费，比如一个计算器功能，我们把加减乘除都做成微服务（即加是微服务，减也是）那么不管是使用者还是提供者都很繁琐，而且容易造成资源浪费，毕竟就算是用容器，容器本身也是需要一个运行环境的；如果不微，把所有功能都糅合到一起，那么哪天更新一个功能可能就要停止所有的服务。造成所有服务中断。
2.微服务的重大优势是什么？它是未来吗？
优势：首先，通过分解巨大单体式应用为多个服务方法解决了复杂性问题。第二，这种架构使得每个服务都可以有专门开发团队来开发。第三，微服务架构模式是每个微服务独立的部署。最后，微服务架构模式使得每个服务独立扩展。
将一个复杂的业务分解成若干小的业务，每个业务拆分成一个服务，服务的边界明确，将复杂的问题简单化。由于微服务系统是分布式系统 ，服务与服务之间没有任何的祸合 。服务与服务之问通过 HTTP 网络通信协议来通信，单个微服务内部高度祸合，服务与服务之间完全独立，无调合。如果是一个单体的应用，由于业务的复杂性、代码的祸合性，以及可能存在的历史问题。微服务的每个服务单元都是独立部署的 ，即独立运行在某个进程里。微服务的修改和部署对其他服务没有影响。微服务在 CAP 理论中采用的是 AP 架构，即 具有高可用和分区容错 的特点 。
微服务（架构）应该是未来软件（架构）的趋势。
3.微服务在实践过程中最大的难点是什么？
『微服务』强调了服务大小，实际上，有一些开发者鼓吹建立稍微大一些的，10-100 LOC服务组。
微服务应用是分布式系统，由此会带来固有的复杂性。开发者需要在RPC或者消息传递之间选择并完成进程间通讯机制。更甚于，他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。当然这并不是什么难事，但相对于单体式应用中通过语言层级的方法或者进程调用，微服务下这种技术显得更复杂一些。
另外一个关于微服务的挑战来自于分区的数据库架构。商业交易中同时给多个业务分主体更新消息很普遍。这种交易对于单体式应用来说很容易，因为只有一个数据库。在微服务架构应用中，需要更新不同服务所使用的不同的数据库。使用分布式交易并不一定是好的选择，不仅仅是因为CAP理论，还因为今天高扩展性的NoSQL数据库和消息传递中间件并不支持这一需求。最终你不得不使用一个最终一致性的方法，从而对开发者提出了更高的要求和挑战。
测试一个基于微服务架构的应用也是很复杂的任务。比如，采用流行的Spring Boot架构，对一个单体式web应用，测试它的REST API，是很容易的事情。反过来，同样的服务测试需要启动和它有关的所有服务（至少需要这些服务的stubs）。再重申一次，不能低估了采用微服务架构带来的复杂性。
另外一个挑战在于，微服务架构模式应用的改变将会波及多个服务。比如，假设你在完成一个案例，需要修改服务A、B、C，而A依赖B，B依赖C。在单体式应用中，你只需要改变相关模块，整合变化，部署就好了。对比之下，微服务架构模式就需要考虑相关改变对不同服务的影响。比如，你需要更新服务C，然后是B，最后才是A，幸运的是，许多改变一般只影响一个服务，而需要协调多服务的改变很少。
部署一个微服务应用也很复杂，一个分布式应用只需要简单在复杂均衡器后面部署各自的服务器就好了。每个应用实例是需要配置诸如数据库和消息中间件等基础服务。
4.微服务、容器技术两者的关系？两者结合带来什么新趋势？
另外一个关于微服务的挑战来自于分区的数据库架构。商业交易中同时给多个业务分主体更新消息很普遍。这种交易对于单体式应用来说很容易，因为只有一个数据库。在微服务架构应用中，需要更新不同服务所使用的不同的数据库。使用分布式交易并不一定是好的选择，不仅仅是因为CAP理论，还因为今天高扩展性的NoSQL数据库和消息传递中间件并不支持这一需求。最终你不得不使用一个最终一致性的方法，从而对开发者提出了更高的要求和挑战。
测试一个基于微服务架构的应用也是很复杂的任务。比如，采用流行的Spring Boot架构，对一个单体式web应用，测试它的REST API，是很容易的事情。反过来，同样的服务测试需要启动和它有关的所有服务（至少需要这些服务的stubs）。再重申一次，不能低估了采用微服务架构带来的复杂性。
另外一个挑战在于，微服务架构模式应用的改变将会波及多个服务。比如，假设你在完成一个案例，需要修改服务A、B、C，而A依赖B，B依赖C。在单体式应用中，你只需要改变相关模块，整合变化，部署就好了。对比之下，微服务架构模式就需要考虑相关改变对不同服务的影响。比如，你需要更新服务C，然后是B，最后才是A，幸运的是，许多改变一般只影响一个服务，而需要协调多服务的改变很少。
部署一个微服务应用也很复杂，一个分布式应用只需要简单在复杂均衡器后面部署各自的服务器就好了。每个应用实例是需要配置诸如数据库和消息中间件等基础服务。
微服务与容器结合能够更好的发挥和充分的利用计算机的资源。
5.怎么处理微服务与外部相连，以及获取数据？
对外部有了依赖
微服务架构设计中有一条重要的原则叫严出宽进，严出意思就是说你提供给其他服务的东西要尽可能的进行严格的校验。宽进就是你调用别人的接口要宽容，兼容各种情况。比如说你需要考虑别人的节点down了/api超时/api不可用等等因素。
为了解决这个问题，我们必须要针对具体业务，分析依赖类型，是强依赖还是弱依赖，强依赖包装成自己的服务异常返回码/或者直接告诉前端调用不可用。弱依赖，catch所有异常，无论依赖方发生什么，不能影响我的接口返回。
此外，我依赖的服务某段时间内接口错误率很高，调用方还在不停的发送请求，那么就会一直得到错误的结果，这时候这些请求其实是无效的，所以这时候需要客户端熔断，不再去调用服务方，给服务方恢复的时间，等过段时间再去重试，发现服务方可用时，再去调用。
网络调用
网络调用是耗时的，所以我们需要利用池化技术，复用连接，比如在单体应用中我们需要与数据库连接，会利用到数据库连接池来提高数据操作效率。那么微服务调用也是这么个道理，我们与其他服务建议http/tcp连接，也需要建立连接池。另外一个服务可能会依赖多个微服务，不能因为和某个服务之间的连接出了问题，影响到与其他服务的连接，所以需要做连接池隔离。
服务间调用有可能失败，所以我们需要有重试机制，比如因为网络抖动引发的超时问题，我们可以通过重试提高API的可用性。
但是思考一下坏的情况，某段时间网络或者服务端真的有问题了。客户端超时时间设置的很大的话，客户端等待的时间就会很长，然后再加上重试机制，就会将客户端的连接占满，造成客户端相关API不可用。
6.微服务与容器结合会发展出新趋势--Cloud Native，什么是Cloud Native？（可选答）
Cloud Native翻译为云原生，是Matt Stine提出的一个概念，它是一个思想的集合，包括DevOps、持续交付（Continuous Delivery）、微服务（MicroServices）、敏捷基础设施（Agile Infrastructure）、康威定律（Conways Law）等，以及根据商业能力对公司进行重组。Cloud Native既包含技术（微服务，敏捷基础设施），也包含管理（DevOps，持续交付，康威定律，重组等）。Cloud Native也可以说是一系列Cloud技术、企业管理方法的集合。
作者: incle 时间: 2019-08-26 15:28
微服务通常由重写一个模块开始。要把整个巨石型的应用重写是有很大的风险的，也不一定必要。我们向微服务迁移的时候通常从耦合度最低的模块或对扩展性要求最高的模块开始，
把它们一个一个剥离出来用敏捷地重写，可以尝试最新的技术和语言和框架，然 后单独布署。 它通常不依赖其他服务。微服务中常用的API Gateway的模式主要目的也不是重用代码，
而是减少客户端和服务间的往来。API gateway模式不等同与Facade模式，我们可以使用如future之类的调用，甚至返回不完整数据。
| 欢迎光临 Chinaunix (http://bbs.chinaunix.net/) |
Powered by Discuz! X3.2 |