欧宝nba直播:分布式服务架构与微服务架构概念的区别与联系是怎样的？
作者：欧宝nba直播在线直播 出处：欧宝odbo官网
，把复杂度很高的产品拆分成一些较小的模块，并遵循康威定律，每一个模块用5-9个小团队来维护，这样可以减少沟通成本，提高协作效率，更好地实现快速迭代和弹性扩展。比如网易考拉，先用网易内部的私有云以及容器服务负载均衡等解决并发流量的问题，再借助网易云轻舟微服务，拆分了 400 多个工程（模块），进一步提升迭代速度和扩展能力，通过服务治理、系统运维自动化等，可以提升可靠性和可用性。这是先有分布化后有服务化的例子。
既没有规模又不需要太多变化的业务，如果采用微服务架构改造，引入各种复杂性，比如部署工作量的增加、复杂链路的监控难题，这就是为微服务而微服务，只会得不偿失。
当然，复杂业务拆分可能无法一步到位，因为复杂，每个业务并不一定只能拆成一个组件，庞大的业务拆分出相对独立和庞大的业务，但如果业务较小而又比较多，且类型相似，也可以不用着急拆分。再举网易考拉的例子，工程数量由最初的 7 到后来的 150+ 再到目前的 400+，都是根据实际情况决定的。中间的状态，可能不是严格意义上的微服务架构，但属于分布式服务架构——不过这不是那么重要，重要的是符合业务发展阶段的需求。医院的急诊，既看发热又看胃痛，固然分工没那么精细，但我们也不能说就是错的。
微服务这个概念最早是在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一般对于客户端的来说是一种同步的远程服务调用技术。与其相对应的，一般来说MQ恰恰是一种异步的调用技术。
2) MQ（Message Queue，消息队列） 异步的远程调用，如果能同时存在很多个请求，该如何处理呢？进一步地，由于不能立即拿到处理结果，假若需要考虑失败策略，重试次数等，应该怎么设计呢？ 如果有N个不同系统相互之间都有RPC调用，这时候整个系统环境就是一个很大的网状结构，依赖关系有N*(N-1)/2个。任何一个系统出问题，都会影响剩下N-1个系统，怎么降低这种耦合呢？如图1-8所示：
基于这些问题，我们发展出来了消息队列（MQ）技术，所有的处理请求先作为一个消息发送到MQ（一般我们叫做broker），接着处理消息的系统从MQ拿到消息并进行处理。这样就实现了各个系统间的解耦，同时可以把失败策略、重试等作为一个机制，对各个应用透明，直接在MQ与各调用方的应用接口层面实现即可，如图1-9所示：
一般来说，我们把发送消息的系统称为消息生产者（message producer），接受处理消息的系统称为消息消费者（message consumer）。
点对点模式（Point to Point，PTP），一个生产者发送的每一个消息，都只能有一个消费者能消费，看起来消息就像从一个点传递到了另外一个点。
发布订阅模式（Publish-Subscribe，PubSub），一个生产者发送的每一个消息，都会发送到所有订阅了此队列的消费者，这样对这个消息感兴趣的系统都可以拿到这个消息。
通过这两种消息模式的灵活应用以及功能扩展，我们可以实现各种具体的消息应用场景，比如高并发下的订单异步处理，海量日志数据的分析处理等等。如果要总结一下消息队列在各类架构设计中能起到的作用，一般有如下几点：
降低系统间的耦合性，无论是开发期的引用关系依赖，还是运行期的调用关系依赖，都明显简化或降低了。通信的双方只需要定义好消息的数据格式（消息头有什么字段，消息体是什么格式的数据），就可以各自开发和测试，最后再各自上线即可集成到一起。
提升了系统间通信可靠性，无论是从通信本身的可靠性上（请求响应机制、重试），还是业务意义上（处理顺序、事务、失败策略），都相比RPC等方式有所增强。
提升了系统的业务缓冲能力，一般又叫削峰填谷，指的是经过MQ做为中间的缓冲，如果业务量突然增大时可以先把处理请求缓冲到队列中，再根据业务消费处理能力逐个消息处理，保障了系统不会因为突然爆发的大量请求而过载瘫痪，影响系统的连续服务能力。
增强了系统的扩展能力，通过消息队列处理的业务，消费端的处理能力如果不够，一般可以随时多加几个消费者来处理，从而可以直接扩展系统的业务处理能力，而不需要额外的代价。
随着目前互联网的飞速发展，我们发现大型项目的设计开发和维护过程中，存在如下几个重点的困难点：
我们之前开发项目用的是虚拟机，每次上线项目需要加机器总会遇到资源不足的情况，还要走非常复杂工单审批流程，还要与运维人员不断PK，才能申请下来资源，整个流程冗长，机器资源申请困难。
部署困难 每次上线采用专门的人进行布署，上线之前需要与上线人员沟通上线的环境，防止上线出错。
发布回滚困难 每次上线发现问题后，需要重新从SVN/GIT主干上面进行代码编译，但是有时候会因为各种问题回滚失败，而且重新编译很耗时导致回滚缓慢。
适配新技术困难 如果打算在不同的模块采用不同的语言开发，或者想在架构中做技术升级都很困难或者不支持。
快速开发困难 复杂项目中采用单体应用或者简单的分拆成2-3个系统，里面集成了太多功能模块，无法快速进行功能开发并且很容易牵一发动全身。
测试困难 测试人员没有自动化测试框架，或者Mock系统，导致只能采用简单的人工测试流程，而且还经常发生功能覆盖不全面等问题。
学习困难 业务变化日新月薪，功能和项目结构都太复杂，整个项目中的逻辑关系相互关联影响，采用的技术五花八门，技术本身的更新换代也很快，导致技术人员学习曲线非常陡峭。
通过几个关键点可以看出微服务重在独立布署和独立业务，而所谓的微服务，并不是越小越好，而是通过团队规模和业务复杂度由粗到细的划分过程，所遵循的原则是松耦合和高内聚，如图1-10所示：
3、微服务与敏捷开发的思想高度结合在一起，服务的定义更加清晰，同时减少了企业ESB开发的复杂性。
使用微服务也就面临着由单体项目向微服务项目过渡，而采用了微服务架构后也就意味着服务之间的调用链路会比以前延长了很多，在调用链路上发生故障的几率也就随之增大，同时调用链路越长，性能越会受影响。微服务架构中是存在很多陷阱的，并不是简单的拿来使用就可以，所以企业要大规模使用微服务不仅仅是从思想和业务上面进行合理划分，还需要诸多技术组件以及高效的运维来协同合作，如图1-11所示。
当请求量较大时，为避免对数据库造成较大压力，可以适当将一些变化较小，读取量较大的数据放入缓存。
超时时间对于调用服务来说非常重要，超时时间设置太长可能会把整体系统拖慢，而设置短了又会造成调用服务未完成而返回，我们在实际工作中需要根据业务场景进行分析，选择一个恰当的超时设定值。
使用熔断器（断路器），当请求下游的服务时发生了一定数量的失败后，熔断器打开，接下来的请求快速返回失败。过一段时间后再来查看下游服务是否已恢复正常，重置熔断器。
当并发量较大，原有服务集群无法满足现有业务场景时，可以采用扩容策略，而当并发量较小时，服务集群可以采用缩容策略，以节省资源。
微服务一般都是分布式的，而微服务更强调敏捷和健壮，他的边界应该更加清晰，包括你部署的程序和数据都应该独立，这里可能借助docker。
上一篇:一年外卖订单144亿笔！美团去年升级战略“零售+科技”后研发投入增长531%
下一篇:分布式关系型数据库双十二优惠活动