下载掌阅APP，畅读海量书库
立即打开
1.1 直面微服务架构 |
|
顾名思义，微服务区别与其他服务体系的关键在于它的“微”特性。“微”是小的同义词，所以容易让人联想到微服务都是小型的服务，这是微服务的第一个特性。微服务之间只有通过相互的协作和交互才能构成完整的服务体系，而这种协作和交互机制也是微服务区别其他服务体系的另一个主要方面。
所谓分布式系统（Distributed System）是指硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。从这个定义中可以看出，分布式系统包含两个区别于单块系统（Monolith System）的本质性特征：一个是网络，分布式系统的所有组件都位于网络之中，对于互联网应用而言，则位于更为复杂的互联网环境中；另一个是通信和协调，与单块系统不同，位于分布式系统中的各个组件只有通过约定、高效且可靠的通信机制进行相关协作，才能完成某一项业务功能。这些特征是我们在设计和实现分布式系统时首先需要考虑的。
分布式系统相较于单块系统在具备一定优势的同时，也存在一些我们不得不考虑的特性，包括但不限于网络传输的三态性、系统之间的异构性、数据一致性、服务的可用性等。以上问题是分布式系统的基本特性，我们无法避免，只能想办法进行利用和管理，这就给我们设计和实现分布式系统提出了挑战。微服务架构本质上也是一种分布式系统，但在遵循通用分布式特性的基础上，微服务架构还表现出一定的特殊特性。下面将围绕微服务架构的这些特殊特性展开讨论。
Martin Fowler指出，微服务架构具有以下特点。
所谓组件（Component）是一种可独立替换和升级的软件单元。在我们日常开发过程中，可能会设计和使用很多组件，这些组件可能服务于系统内部，也可能存在于系统所运行的进程之外。而服务就是一种进程外组件，服务之间利用诸如RPC（Remote Procedure Call，远程过程调用）等通信机制完成交互。服务组件化的主要目的是服务可以独立部署。如果某个应用程序是由一个运行在独立进程中的很多组件组成，那么对任何一个组件的改变都将导致整个应用程序必须重新部署。但是如果把应用程序拆分成很多服务，通常情况下，只需要重新部署那个改变的服务即可。在微服务架构中，每个服务运行在其独立的进程中，服务与服务之间采用轻量级通信机制互相沟通。
在寻找把一个大的应用程序进行拆分的方法时，研发过程一般都会围绕产品团队、UED团队、APP前端团队和服务器端团队而展开，这些团队也就是通常所说的职能团队（Function Team）。当使用这种模式对团队进行划分时，任何一个需求变更，无论大小，都将导致跨团队协作，从而增加沟通和协作成本。而微服务架构下的划分方法则有所不同，它倾向于围绕业务功能的组织来分割服务。这些服务面向的是具体业务结构，而不是面向某项技术能力。因此，团队是跨职能的（Cross-Functional）特征团队（Feature Team），包含用户体验、项目管理和技术研发等开发过程所要求的所有技能。每个服务都围绕着业务进行构建，并且能够被独立地部署到生产或类生产环境。
服务集中治理的一种好处是在单一平台上进行标准化，而采用微服务的团队更喜欢不同的标准。把集中式系统中的组件拆分成不同的服务，我们在构建这些服务时就会有更多的选择。对具体的某一个服务而言，应该根据业务上下文，选择合适的语言和工具进行构建。
此外，微服务架构也崇尚于对数据进行分散管理。当集中式的应用使用单一逻辑数据库进行数据持久化时，通常选择在应用的范围内使用一个数据库。然后，微服务让每个服务管理自己的数据库，无论是相同数据库的不同实例，还是不同的数据库系统。
许多使用微服务架构的产品或者系统，它们的团队拥有丰富的持续集成（Continuous Integration）和持续交付（Continuous Delivery）经验。团队使用微服务架构构建软件需要更广泛的依赖基础设施自动化技术。
在微服务中同样需要考虑服务容错性设计等分布式系统所需要考虑的问题，我们对以上特点进行总结和提炼，认为微服务具备业务独立、进程隔离、团队自主和交付独立性等“微”特性。
微服务并不是一个纯技术的事物，而是涉及业务边界、基础设施、组织架构等的综合体系。微服务架构存在明显的优势，但也面临着各种挑战。
微服务架构能够为我们带来许多优势，包括技术上的优势、业务结构上的优势及组织上的优势。
微服务架构提供的是一种高内聚、低耦合的组件化方案。组件所能带来的独立性与健壮性微服务都可以具备，但是微服务的组件化特征更多的表现在对业务的提炼和对边界的思考。使用微服务架构迫使我们使用诸如领域驱动设计（Domain Driven Design，DDD）的思想去开展策略设计和技术设计，从而为更好地划分业务功能、提取界限上下文和开展系统集成工作提供依据。而这些方法和依据的背后恰恰是我们在架构设计过程中经常会碰到的问题。
当系统架构转变成一系列微服务之间的通信和集成时，我们就明白具体实现技术已经不是系统设计和开发的主要约束条件。因为在微服务架构中，各个微服务之间使用的是轻量级的通信机制。所谓轻量级是指这些通信机制与具体实现技术无关，不受限于某一个特定协议或交互媒介。每个微服务高度独立，可以采用适合自身开发团队和技术体系的工具及框架来实现某个微服务，从而为我们提供了宝贵的技术自由度。
在微服务架构中，通过服务拆分与集成，单个服务在保持通信方式不变的前提下，对其内部功能和技术的改变不会对外部依赖它的服务产生任何影响。结合可扩展性的概念，微服务架构无疑具备这方面的优势。高扩展性往往能够带来高可伸缩性，因为可以伸缩的前提是对系统进行合理地拆分。当我们明确系统的运行瓶颈，并把引起这些瓶颈的业务功能构建成独立的微服务，就可以采用服务集群等手段有效加强服务的运行环境和状态。
微服务是可用于改造遗留系统（Legacy System）的强有力武器。面对遗留系统，一方面该系统的技术体系可能存在设计上的重大缺陷，另一方面则是因为代码量巨大且不容易修改。在代码层次与遗留系统进行直接集成是痛苦且具有挑战性的工作，但是遗留系统以提供接口的方式暴露某些功能入口仍然是一个相对容易实现的过程。一旦获取这些接口，微服务架构就能与之进行通信并完成功能整合。
持续交付通过简单、可重复的流程来确保软件发布过程的可靠性，微服务作为独立的可部署单元，非常适合使用持续交付，因为每一项服务都可以在不依赖于其他服务的条件下完成发布和部署。基于微服务架构，持续交付管道可以运行得更快，从而加速问题反馈，这是持续交付的主要目标之一。而持续交付的另一个目标是降低系统风险，微服务小而独立，一旦出现问题很容易进行修复和回滚操作。
微服务架构的技术特征决定了开发各自微服务的团队之间只需要进行较少的协调工作，这为降低研发过程浪费提供了基础。从组织管理的角度出发，自治式团队较之集中式管理模式下的团队在团队建立和发展上能够得到更好的可扩展性。集中式团队普遍受限于技术上的约束和决策，诸如可用性、性能等非功能性需求都不是由某个业务功能和系统的独立团队所负责，而是需要集中式的、系统级别的实现和管理。微服务架构可以把大型团队打散成小型团队，小型团队比大型团队具有更低的失败可能性。从这点上讲，微服务架构还能够降低团队组织级别的风险。
微服务架构从技术角度给出了缩短产品开发周期的方法，主要表现在并行的开发模式上。将业务拆分成多个微服务能够让不同的业务功能处于一种并行开发的状态，因为每个团队所负责的业务需求只影响到团队自身的微服务，所以各个团队能够独立开发，整个系统也很容易分布到各个团队中。如果涉及简单业务需求的变更或者是发布部署的要求，独立的微服务之间也不需要太多的统一协调工作。大规模的统一协调工作通常只发生在业务结构产生重大变更的场景，而这种场景对于软件开发而言显然是应该尽量避免并进行提前规划。
将一个系统分散到多个微服务中使得系统整体结构变得更加复杂，这在技术架构和研发过程中同样给我们带来了一定挑战。
微服务架构所带来的独立性可能导致每个服务采用不同的技术体系。去中心化的设计思想意味着微服务之间不需要共享技术，然而缺少通用的技术体系同样也会加剧系统开发的复杂度。去中心化是微服务架构的基本特征之一，但当每个微服务团队都采用自身团队擅长的技术进行微服务构建时，导致的问题就是没有一个人能够明白系统中所采用的所有技术。尽管多数情况下，我们并不需要深入到其他团队的微服务中，但从统一发布和运维等角度去看待整个系统时，这种技术复杂性就可能会是一个问题。我们需要把控中心化和去中心化之间的平衡性。
每个微服务都应该具备与其他服务保持相互独立的版本控制机制，我们提倡为每个微服务建立版本并根据业务迭代更新这个版本。如果每个服务都能够完全按照自身服务的演进过程进行独立发布，那么事情还比较简单。但如果某一个服务与另一个服务具有版本关联性，即这两个服务要不都不发布，要不一起发布，那么事情就变得复杂了。如果这些具有版本关联性的服务很多且版本的更新频率很高，如何正确管理服务版本就是一项具有挑战性的工作。
对研发过程而言，分散的服务在一定程度上等同于分散的业务需求，来源于微服务具有的业务独立性和明确的服务边界。但对于整个系统而言，需求的边界并不那么容易划分。当我们面对微服务架构，如何确定业务功能的粒度，如何把非功能性需求分解到各个微服务中，如何从系统整体上把握需求的优先级等都是我们不得不面对的问题。
对于大多数尚未采用微服务架构的团队而言，使用微服务架构就是一个引入变化的过程。关于这一点，很多人都存在一定的误解，最大的误解就是认为新想法一旦引入就意味着已经成功了。当我们尝试采用微服务架构时，团队管理人员想了很多办法、做了很多工作找到了问题的切入点，跟各个利益方讨论之后终于引入了大家都赞同的变化，然后就期望这个变化能按照自己想的那样发挥效果，这是不对的。当微服务架构被引入后，我们还要做很多事情，前面所提到的各种技术、架构和过程的挑战都需要我们进行跟踪和协调。
实施微服务架构存在固定的模式，最典型的实施模式是从一个单块系统逐步转变为多个维度的微服务架构。通常，不同的业务功能根据优先级、工作量等可以转化为一个一个的微服务。促使这种转变的主要目的可能来自于业务的快速变化和迭代要求，或者来自于将系统的部署与运维变得独立而简单，而更为重要的原因则可能来自于对架构可扩展性和可伸缩性的考虑。当然，从单块系统转变为微服务架构在方式上不同团队、不同场景可能也存在差异性，对于那些对服务的可用性要求很高的场景而言，可以先通过使用一些服务隔离手段设法提高服务的整体可靠性之后再拆分微服务；而有些场景下，对业务的分离可能是系统的最大痛点，那么快速、合理的拆分业务就是实施微服务架构的第一步。
当然，现实中也存在从无到有实施微服务架构的机会，尽管这种机会非常少见。即使有这种机会，一般的做法也是先构建一个单块系统，然后再设法加以改进，因为从无到有的过程就是一个从小到大的过程，而从微服务实施的前提上讲，小系统没有必要直接采用微服务架构。但在系统架构的初始设计阶段，采用领域驱动的设计思想建立粗粒度的领域模型是一种最佳实践，有助于后续向微服务架构转型的实施过程。领域驱动设计同样也驱使技术团队在设计阶段就考虑到合适的团队分工和各个团队之间的独立性。
混合式是尝试微服务架构的第三种方式，因为微服务架构很容易与现有系统并存，这些微服务能够很好的对系统起到补充作用。如果需要，我们能够很快实现很多微服务，而一旦出现问题，移除这些微服务的成本也较低。微服务与遗留系统之间的易整合性是我们采用微服务的一个主要原因，关于这种整合关系及其实施方法可参考笔者所著的《微服务设计原理与架构》一书中的内容。