微服务(Martin Fowler原文翻译).docxVIP

微服务(Martin Fowler翻译) 2021-04-13 微服务 一个新的架构术语 “微服务架构”一词是在过去几年里涌现出来的，它用于描述一种独立部署的软件应用设计方式。这种架构方式并没有格外明确的定义，但有一些共同的特点就是围绕在业务力量、自动化布署、端到端的整合以及言语和数据的分散把握上面。 “微服务”- 这是在软件架构领域这个格外拥堵的街道上，冒出的一个新名词而已。虽然我们对这个新出的名词不屑一顾，但是它所描述的软件系统的风格越来越吸引我们的留意力。在过去的几年里，我们发觉越来越多的项目开头使用这个风格，并且到目前为止得到的反馈都是乐观的，以至于我身边的很多同事在设计企业架构时，都把它作为默认的构建方式，然而很不幸，到底什么是微服务，我们又如何来使用它，外界并没有太多的信息可供参考。 总之，微服务这种架构风格就是把一组小服务演化成为一个单一的应用的一种方法。每个应用都运转在本人的进程中，并通过轻量级的机制保持通信，就像HTTP这样的API。这些服务要基于业务场景，并使用自动化布署工具进行独立的发布。可以有一个格外轻量级的集中式管理来协调这些服务，可以使用不同的言语来编写服务，也可以使用不同的数据存储。 在开头解释什么是微服务之前，先引见一下单体应用还是很有用的：把一个单体应用构建成为一个部分。企业应用通过是由三个重要部分组成：客户端界面（由HTML、JavaScript组成，使用扫瞄器进行访问）、数据库（由很多的表组件构成一个通用的、相互关联的数据管理系统）、服务端应用。服务端应用处理HTTP恳求、执行领域规律、检索并更新数据库中的数据、选择和填充HTML视图发送给客户端。这个服务端应用是一个单块结构也就是一个全体，这是一个可执行的单一规律，系统中的任何修改都将导致服务端应用重新编译和布署一个新版本。 就这样一个单体应用很自然的被构建成了一个系统，虽然可以使用开发言语基本特性会把应用封装成类、函数、命名空间，但是业务中全部恳求都要在单一的进程中处理完成，在某些场景中，你可以在开发人员的笔记本电脑中运转和测试，并且通过布署通道将测试通过的程序布署到生产环境中，你还可以水平扩展，利用负载均衡将实例布署到多台服务器中。 的确，单体应用也是很成功的，但是越来越多的人感觉到了不妥，特殊是应用程序被发布到了云的时候，变更发布周期被绑定了 —- 原来可以划分成小的应用、小的需要的变更，需要统一的进行编译和发布。随着时间的推移，软件开发者很难保持原有好的模块架构，使得一个模块的变更很难不会影响到其它的模块，而且在扩展方面也只能进行全体的扩展，而不能依据进行部分的扩展。? 这些缘由导致了微服务架构风格的消灭：以服务构建应用。这些服务还可以被独立布署、独立扩展，每个服务也都供应了清楚的模块边界，甚至不同的服务都可以使用不同的编程言语来实现，也可以由不同的团队进行管理。 微服务的概念不是我们创造的，它至少起源于Unix时代的设计准绳，我们认为这种风格所带来的好处，并没有引起足够多人的注重。 微服务架构特征 我们没有方法对微服务有一个正式的定义，但我们可以尝试表述适合这种架构的共同特征来给它打上特性标签，共同特性并不代表每个服务都具备这些特点，但是我们真的期望大多数微服务架构能具备其中大部分特点。虽然我们的作者已经是松散社区的核心成员，但是我们也在尝试描述我们工作中或者我们了解的组件中所理解的微服务。我们并不依靠于那些已经明确过的定义。 组件化与服务 只需我们一直在从事软件行业，我们的愿望就是，软件由很多组件组装在一起，犹如物理现实世界中类似的构造方式。在过去的几十年里，我们已经看到了大部分言语平台公共库有了长足的进步。 当我们在谈论组件时，我们遇到了组件定义方面的困难，我们给定的定义是：一个组件是软件中的一个部分，可以独立的替换和升级。 微服务也会使用组件库，将一个软件组件化的次要方式就是将其分解成服务，我们定义的库是可以连接到程序并使用内存函数的的组件库，服务是进程外的组件，如Web恳求服务或者近程调用来相互通信的组件。（这种定义的方式与其它面对对象程序中服务对象的概念是不一样的。） 把服务当成组件（而不是组件库）的一个缘由是服务可以独立布署，假如你有一个应用是由多个库组成并且运转在一个进程中，那么任何一点的转变都会引起整个应用的重新发布，但是将这个应用拆解为多个服务，你可以期盼每个服务的变更仅需要发布相应的服务就可以，当然这也不是确定的，比如导致服务接口变更的更新就需要相应服务的变化，但是良好的架构设计是通过聚合服务边界并且依据合约实现服务演化，最大限度地削减由于转变影响其他地方。 把服务当成组件的另一个考虑是这会拥有愈加清楚的接口，大多数的言语并没有一个很好的机制来定义一个明确显式的发布接口，通常只要文档和规范说明