SpringBoot-了解微服务(二)

什么是微服务？

微服务是一种架构风格，它要求咱们在开发一个应用的时候，这个应用必须构建成一系列小服务的组合；

能够经过http的方式进行互通。

要说微服务架构，先了解一下之前的单体应用架构

单体应用架构

所谓单体应用架构是指，咱们将一个应用的中的全部应用服务都封装在一个应用中。

不管是ERP、CRM或是其余什么系统，你都把数据库访问，web访问，等等各个功能放到一个war包内。

这样作的好处是，易于开发和测试；也十分方便部署；当须要扩展时，只须要将war复制多份，而后放到多个服务器上，再作个负载均衡就能够了。

单体应用架构的缺点是，哪怕我要修改一个很是小的地方，我都须要停掉整个服务，从新打包、部署这个应用war包。特别是对于一个大型应用，咱们不可能吧全部内容都放在一个应用里面，咱们如何维护、如何分工合做都是问题。

一旦您的应用程序成为了一个庞大、复杂的单体，您的开发组织可能会陷入了一个痛苦的境地，敏捷开发和交付的任何一次尝试都将原地徘徊。一个主要问题是应用程序实在很是复杂。对于任何一个开发人员来讲显得过于庞大.复杂的单体应用自己就是持续部署的障碍,当不一样模块存在资源需求冲突时，单体应用可能难以扩展

微服务架构

单体应用的架构方式，咱们把全部的功能单元放在一个应用里面。而后咱们把整个应用部署到服务器上。若是负载能力不行，咱们将整个应用进行水平复制，进行扩展，而后在负载均衡。

所谓微服务架构，就是打破以前单体架构方式，把每一个功能元素独立出来。把独立出来的功能元素的动态组合，须要的功能元素才去拿来组合，须要多一些时能够整合多个功能元素。因此微服务架构是对功能元素进行复制，而没有对整个应用进行复制。

这样作的好处是：

（1）节省了调用资源。

（2）每一个功能元素的服务都是一个可替换的、可独立升级的软件代码。

微服务架构模式相似于 SOA。微服务是由一组服务组成。然而，换另外一种方式去思考微服务架构模式，它是没有商业化的 SOA，没有集成 Web 服务规范 (WS-) 和企业服务总线 (Enterprise Service Bus， ESB) 。基于微服务的应用支持更简单、轻量级的协议，例如，REST，而不是 WS-。他们也尽可能避免使用 ESB，而是实现微服务自己具备相似 ESB 的功能。微服务架构也拒绝了 SOA 的其余部分，例如，数据访问规范模式概念。

微服务的优势

概述

微服务架构模式有许多很是好的地方。

第一，它解决了复杂问题。它把可能会变得庞大的单体应用程序分解成一套服务。虽然功能数量不变，可是应用程序已经被分解成可管理的块或者服务。每一个服务都有一个明肯定义边界的方式，如远程过程调用（RPC）驱动或消息驱动 API。微服务架构模式强制必定程度的模块化，实际上，使用单体代码来实现是极其困难的。所以，使用微服务架构模式，个体服务能被更快地开发，并更容易理解与维护。

第二，这种架构使得每一个服务均可以由一个团队独立专一开发。开发者能够自由选择任何符合服务 API 契约的技术。固然，更多的组织是但愿经过技术选型限制来避免彻底混乱的状态。然而，这种自由意味着开发人员再也不有可能在这种自由的新项目开始时使用过期的技术。当编写一个新服务时，他们能够选择当前的技术。此外，因为服务较小，使用当前技术重写旧服务将变得更加可行。

第三，微服务架构模式能够实现每一个微服务独立部署。开发人员根本不须要去协调部署本地变动到服务。这些变动一经测试便可当即部署。好比，UI 团队能够执行 A|B 测试，并快速迭代 UI 变动。微服务架构模式使得持续部署成为可能。

最后，微服务架构模式使得每一个服务可以独立扩展。您能够仅部署知足每一个服务的容量和可用性约束的实例数目。此外，您可使用与服务资源要求最匹配的硬件。例如，您能够在 EC2 Compute Optimized 实例上部署一个 CPU 密集型图像处理服务，而且在 EC2 Memory-optimized 实例上部署一个内存数据库服务。

微服务的缺点

概述

微服务架构模式也存在着缺点。其中一个缺点就是名称自己。微服务这个术语的重点过多偏向于服务的规模。事实上，有些开发者主张构建极细粒度的 10 至 100 LOC（代码行） 服务，虽然这对于小型服务可能比较好，但重要的是要记住，小型服务只是一种手段，而不是主要目标。微服务的目标在于充分分解应用程序以方便应用敏捷开发和部署。

微服务另外一个主要缺点是因为微服务是一个分布式系统，其使得总体变得复杂。开发者须要选择和实现基于消息或者 RPC 的进程间通讯机制。此外，因为目标请求可能很慢或者不可用，他们必需要编写代码来处理局部故障。虽然这些并非很复杂、高深，但模块间经过语言级方法/过程调用相互调用，这比单体应用要复杂得多。

微服务的另外一个挑战是分区数据库架构。更新多个业务实体的业务事务是至关广泛的。这些事务在单体应用中的实现显得微不足道，由于单体只存在一个单独的数据库。在基于微服务的应用程序中，您须要更新不一样服务所用的数据库。一般不会选择分布式事务，不只仅是由于 CAP 定理。他们根本不支持现在高度可扩展的 NoSQL 数据库和消息代理。您最后不得不使用基于最终一致性的方法，这对于开发人员来讲更具挑战性。

测试微服务应用程序也很复杂。例如，使用现代框架如 Spring Boot，只须要编写一个测试类来启动一个单体 web 应用程序并测试其 REST API。相比之下，一个相似的测试类对于微服务来讲须要启动该服务及其所依赖的全部服务，或者至少为这些服务配置存根。再次声明，虽然这不是一件高深的事情，但不要低估了这样作的复杂性。

微服务架构模式的另外一个主要挑战是实现了跨越多服务变动。例如，咱们假设您正在实现一个变动服务 A、服务 B 和 服务 C 的需求，其中 A 依赖于 B，且 B 依赖于 C。在单体应用程序中，您能够简单地修改相应的模块、整合变动并一次性部署他们。相反，在微服务中您须要仔细规划和协调出现的变动至每一个服务。例如，您须要更新服务 C，而后更新服务 B，最后更新服务 A。幸运的是，大多数变动只会影响一个服务，须要协调的多服务变动相对较少。

部署基于微服务的应用程序也是至关复杂的。一个单体应用能够很容易地部署到基于传统负载均衡器的一组相同服务器上。每一个应用程序实例都配置有基础设施服务的位置（主机和端口），好比数据库和消息代理。相比之下，微服务应用程序一般由大量的服务组成。例如，据 Adrian Cockcroft 了解到，Hailo 拥有 160 个不一样的服务，Netflix 拥有的服务超过 600 个。

每一个服务都有多个运行时实例。还有更多的移动部件须要配置、部署、扩展和监控。此外，您还须要实现服务发现机制，使得服务可以发现须要与之通讯的任何其余服务的位置（主机和端口）。比较传统麻烦的基于票据（ticket-based）和手动的操做方式没法扩展到如此复杂程度。所以，要成功部署微服务应用程序，须要求开发人员能高度控制部署方式和高度自动化。

一种自动化方式是使用现成的平台即服务（PaaS），如 Cloud Foundry。PaaS 为开发人员提供了一种简单的方式来部署和管理他们的微服务。它让开发人员避开了诸如采购和配置 IT 资源等烦恼。同时，配置 PaaS 的系统人员和网络专业人员能够确保达到最佳实践以落实公司策略。

自动化微服务部署的另外一个方式是开发本身的 PaaS。一个广泛的起点是使用集群方案，如 Kubernetes，与 Docker 等容器技术相结合。

小结

构建复杂的微服务应用程序本质上是困难的。单体架构模式只适用于简单、轻量级的应用程序，若是您使用它来构建复杂应用，您最终会陷入痛苦的境地。微服务架构模式是复杂、持续发展应用的一个更好的选择。尽管它存在着缺点和实现挑战。

3.CAP 定理

2000 年 7 月，加州大学伯克利分校的 Eric Brewer 教授在 ACM PODC 会议上提出 CAP 猜测。2年后，麻省理工学院的 Seth Gilbert 和 Nancy Lynch 从理论上证实了 CAP。以后，CAP 理论正式成为分布式计算领域的公认定理。

CAP 理论为：一个分布式系统最多只能同时知足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。

• 一致性(Consistency)： 一致性指 (all nodes see the same data at the same time)，即更新操做成功并返回客户端完成后，全部节点在同一时间的数据彻底一致。
• 可用性(Availability)： 可用性指(Reads and writes always succeed)，即服务一直可用，并且是正常响应时间。
• 分区容错性(Partition tolerance)： 分区容错性指(the system continues to operate despite arbitrary message loss or failure of part of the system)，即分布式系统在遇到某节点或网络分区故障的时候，仍然可以对外提供知足一致性和可用性的服务。

CAP 权衡

经过 CAP 理论，咱们知道没法同时知足一致性、可用性和分区容错性这三个特性，那要舍弃哪一个呢？

对于多数大型互联网应用的场景，主机众多、部署分散，并且如今的集群规模愈来愈大，因此节点故障、网络故障是常态，并且要保证服务可用性达到 N 个 9，即保证 P 和 A，舍弃C（退而求其次保证最终一致性）。虽然某些地方会影响客户体验，但没达到形成用户流程的严重程度。

对于涉及到钱财这样不能有一丝让步的场景，C 必须保证。网络发生故障宁肯中止服务，这是保证 CA，舍弃 P。貌似这几年国内银行业发生了不下 10 起事故，但影响面不大，报道也很少，广大群众知道的少。还有一种是保证 CP，舍弃 A。例如网络故障是只读不写。

孰优孰略，没有定论，只能根据场景定夺，适合的才是最好的。

4.BASE 理论

eBay 的架构师 Dan Pritchett 源于对大规模分布式系统的实践总结，在 ACM 上发表文章提出 BASE 理论，BASE 理论是对 CAP 理论的延伸，核心思想是即便没法作到强一致性（Strong Consistency，CAP 的一致性就是强一致性），但应用能够采用适合的方式达到最终一致性（Eventual Consitency）。

• 基本可用(Basically Available)： 基本可用是指分布式系统在出现故障的时候，容许损失部分可用性，即保证核心可用。电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现。
• 软状态(Soft State)： 软状态是指容许系统存在中间状态，而该中间状态不会影响系统总体可用性。分布式存储中通常一份数据至少会有三个副本，容许不一样节点间副本同步的延时就是软状态的体现。MySQL Replication 的异步复制也是一种体现。
• 最终一致性(Eventual Consistency)： 最终一致性是指系统中的全部数据副本通过必定时间后，最终可以达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊状况。

5.ACID 和 BASE 的区别与联系

ACID 是传统数据库经常使用的设计理念，追求强一致性模型。BASE 支持的是大型分布式系统，提出经过牺牲强一致性得到高可用性。

ACID 和 BASE 表明了两种截然相反的设计哲学，在分布式系统设计的场景中，系统组件对一致性要求是不一样的，所以 ACID 和 BASE 又会结合使用。