微服务基础知识

1 系统架构的演变

1.1 概述

• 随着互联网的发展，网站应用的规模不断扩大，常规的应用架构已无法应对，分布式服务架构以及微服务架构势在必行，亟需一个治理系统确保架构有条不紊的演进。

1.2 单体应用架构

• web应用程序发展的早期，大部分web工程（包含前端页面，web层代码，service层代码，dao层代码）是将所有的功能模块，打包到一起并放在一个web容器中运行。

• 比如搭建一个电商系统：客户下订单，商品展示，用户管理。这种将所有功能度部署在一个web容器中运行的系统就叫做单体架构，目前也有人称为单体地狱。
• 优点：
  • 1️⃣所有的功能集成在一个项目工程中。
  • 2️⃣项目架构简单，前期开发成本低，周期短，小型项目的首选。
• 缺点：
  • 1️⃣全部功能集成在一个工程中，对于大型项目不易开发、扩展和维护。
  • 2️⃣系统性能只能通过扩展集群结点，成本高，有瓶颈。
  • 3️⃣技术栈受限。
  • 4️⃣代码耦合度很高。
  • 5️⃣容错性差，比如用户管理出问题了，整个系统全部出问题，牵一发而动全身。

1.3 垂直应用架构

• 当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互补相干的几个应用，以提高效率。

• 优点：
  • 1️⃣项目架构简单，前期开发成本低，周期daunt，小型项目的首选。
  • 2️⃣通过垂直拆分，原来的单体项目不至于无线扩大。
  • 3️⃣不同的项目可采用不同的技术。
  • 4️⃣针对不同的子工程优化。
  • 5️⃣解决高并发问题。
  • 6️⃣方便水平扩展，容错性好（相对于单体架构来说的，比如上图中的商品管理出问题了，对CMS系统和后台管理系统来说没影响）。
• 缺点：
  • 1️⃣全部功能集成在一个工程中，对于大型项目不易开发、扩展和维护。
  • 2️⃣系统性能扩展只能通过扩展集群结点，成本高，有瓶颈。
  • 3️⃣系统间相互独立，会产生session共享问题（可以使用Redis Cluster、SpringSession等技术解决）。
  • 4️⃣重复的开发工作（比如上图中的用户管理功能在电商系统和后台管理系统中都有）。

1.4 分布式SOA架构

1.4.1 什么是SOA？

• SOA，全称是Service-Oriented Architecture，即面向服务的架构。它可以根据需要通过网络对松散耦合的粗粒度应用组件（服务）进行分布式部署、组合和使用。一个服务通常以独立的形式存在于操作系统进程中。
• 站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生，目的是把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用。
• 通过上面的描述可以发现SOA有如下的特点：分布式、可重用、扩展灵活、松耦合。

1.4.2 SOA架构

• 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使得前端应用能够更快速的响应多变的市场需求。

• 优点：
  • 1️⃣抽取公共的功能为服务，提高开发效率。
  • 2️⃣对不同的服务进行集群化部署解决系统压力。
  • 3️⃣基于ESB或Dubbo减少系统耦合。
• 缺点：
  • 1️⃣抽取服务的粒度较大。
  • 2️⃣服务提供方和调用方接口耦合度较高。

1.5 微服务架构

• 优点：
  • 1️⃣通过服务的原子化拆分，以及微服务的独立打包、部署和升级，小团队的交付周期将会缩短，运维成本也将大幅度下降。
  • 2️⃣微服务遵循单一原则。微服务之间采用RESTful等轻量级协议传输。
• 缺点：
  • 1️⃣微服务过多，服务治理成本高，不利于系统维护。
  • 2️⃣分布式系统开发的技术成本高（容错、分布式事务等）。

1.6 SOA和微服务的关系

• SOA：面向服务的架构，是一种设计方法，其中包含多个服务，服务和服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在于操作系统的进程之中。各个服务之间通过网络调用。
• 微服务架构：其实和SOA架构类似，微服务是SOA架构上的升华，微服务架构强调的一个重点是"业务需要彻底的组件化和服务化"，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。

功能	SOA	微服务
组件大小	大块业务逻辑	单独任务或小块业务逻辑
耦合	通常松耦合	总是松耦合
公司架构	任何类型	小型，专注于功能交叉团队
管理	着重中央管理	着重分散管理
目标	确保应用能够交互操作	执行新功能、快速拓展开发团队

2 分布式核心知识

2.1 分布式的远程调用

• RESTful。
• RPC。

2.2 分布式中的CAP原理

• 现如今，对于大多数大型互联网应用，分布式系统正变得越来越重要。分布式系统最大的难点，就是各个节点的状态如何同步。CAP定理是这方面的基本定理，也是理解分布式系统的起点。
• CAP理论有Eirc Brewer在ACM研讨会上提出的，而后CAP被奉为分布式领域的重要理论。分布式系统的CAP理论，首先把分布式系统中的三个特性进行了如下的归纳。

• C（Consistency，一致性）：数据一致更新，所有数据的变化都是同步的。
• A（Availability，可用性）：在集群中一部分节点故障后，集群整体是否还能有影响客户端的读写请求。
• P（Partition tolerance，分区容错性）：某个节点的故障，并不影响整个系统的运行。

一个分布式系统里面，节点组成的网络本来应该是连通的。然而可能因为一些故障，使得有些节点之间不连通了，整个网络就分成了几块区域。数据就散布在了这些不连通的区域中。这就叫分区。

当你一个数据项只在一个节点中保存，那么分区出现后，和这个节点不连通的部分就访问不到这个数据了。这时分区就是无法容忍的。

提高分区容忍性的办法就是一个数据项复制到多个节点上，那么出现分区之后，这一数据项就可能分布到各个区里。容忍性就提高了。

然而，要把数据复制到多个节点，就会带来一致性的问题，就是多个节点上面的数据可能是不一致的。要保证一致，每次写操作就都要等待全部节点写成功，而这等待又会带来可用性的问题。

总的来说就是，数据存在的节点越多，分区容忍性越高，但要复制更新的数据就越多，一致性就越难保证。为了保证一致性，更新所有节点数据所需要的时间就越长，可用性就会降低。

作者：邬江
链接：https://www.zhihu.com/question/54105974/answer/139037688
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

选择	说明
CA	放弃分区容错性，加强一致性和可用性，其实就是传统的关系型数据库的选择
AP	放弃一致性（强一致性），追求分区容错性和可用性，这时很多分布式系统设计时的选择，比如很多NoSQL数据库就是如此
CP	放弃可用性，追求一致性和分区容错性，基本不会选择，网络问题会直接让整个系统不可用，比如zookeeper就是CP

• 需要明确一点的是，在一个分布式系统当中，分区容错性和可用性是最基本的需求，所以在分布式系统中，我们的系统最应该关注的是AP，通过补偿机制寻求数据的一致性。

3 常见微服务框架

3.1 SpringCloud

• SpringCloud是一系列框架的有序集合。它利用SpringBoot的开发便利性巧妙的简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息中线、负载均衡、熔断器、数据监控等，都可以用SpringBoot的开发风格做到一键启动和部署。SpringCloud并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考研的服务框架组合起来，通过SpringBoot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

3.2 Apache的ServiceComb

• Apache ServiceCombo是业界第一个Apache微服务顶级项目，是一个开源微服务解决方案，致力于帮助企业、用户和开发者将企业应用轻松微服务化上云，并实现对微服务应用的高效运维管理。其提供一站式开源微服务解决方案，融合SDK框架级、零入侵ServerMesh场景并支持多种语言。

3.3 ZeroC ICE

• Zeroc ICE是Zeroc公司的杰作，继承了CORBA的血统，是新一代的面向对象的分布式系统中间件。作为一种微服务架构，它基于RPC框架发展而来，具有良好的性能和分布式能力。