本文主要是介绍微服务 个人理解+翻译，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

微服务

微服务
英文原文

微服务架构风格，就像是把一个单独的应用程序开发为一套小服务，每个小服务运行在自己的进程中，并使用轻量级机制通信，通常是 HTTP。这些服务围绕业务能力来构建，并通过完全自动化部署机制来独立部署。这些服务使用不同的编程语言书写，以及不同数据存储技术，并保持最低限度的集中式管理。

微服务与整体风格（单体应用）的比较

单体应用

企业级应用（单体应用）通常被构建成三个主要部分：

• 客户端用户界面（由运行在客户机器上的浏览器的 HTML 页面、Javascript 组成）、
• 数据库（由许多的表构成一个通用的、相互关联的数据管理系统）、
• 服务端应用。 服务端应用处理 HTTP 请求，执行领域逻辑（domain logic），检索并更新数据库中的数据。

服务端应用是完整的 ，是一个单独的的逻辑执行。任何对系统的改变都涉及到重新构建和部署一个新版本的服务端应用程序。（即任何一个小改动就要重新部署整个项目）

这样的整体服务（monolithic server）是一种很常用构建系统的方式。尽管可以利用开发语基础特性把应用程序划分成类、函数、命名空间，但所有处理请求的逻辑都运行在一个单独的进程中。开发、测试简单，不涉及到应用之间的互联互调。部署也很简单。只需将整个应用打成war包，横向扩展，通过负载均衡将多个应用部署到多台服务器上。

整体应用程序（Monolithic applications）应用相当广泛，但是越来越多的人认为该架构存在问题，特别是在云中部署时。变更发布周期被绑定了——**只是变更应用程序的一小部分，就要求整个重新构建和部署。**随着时间的推移，很难再保持一个好的模块化结构，使得一个模块的变更很难不影响到其它模块。扩展就需要整个应用程序的扩展，而不能进行部分扩展。

微服务

微服务：可以独立部署和扩展，每个服务拥有模块边界，甚至不同的服务可以用不同的编程语言编写。它们可以被不同的团队管理。
每一个功能元素最终都是一个可独立替换、独立升级的软件单元。

组件化（Componentization ）与服务（Services）区别

**组件（component）**是一个可独立替换和升级的软件单元。我们把库定义为组件，这些组件被链接到程序，并通过内存中函数调用来调用，即”组件”是指这样一个软件单元：它将被组件作者无法控制的其他应用程序使用，但后者不能对组件进行修改。也就是说，使用一个组件的应用程序不能修改组件的源代码，但可以通过作者预留的某种途径对其进行扩展，以改变组件的行为。

微服务架构会使用库，使用的是进程外组件，他们利用某个机制通信，比如 WebService 请求，或远程过程调用。

服务的本质是一个对外部开放的接口，而组件的本质是一个能够被复用的封装体，一个讲求对外服务，一个讲求被复用。
另一方面：组件是在本地使用的（例如JAR文件、程序集、DLL、或者源码导入）；而服务是要通过同步或异步的远程接口来远程使用的（例如web service、消息系统、RPC，或者socket）。

微服务与整体风格的业务功能组织

整体风格：设计一个系统时，将人员划分为 UI 团队，中间件团队，DBA 团队，那么相应地，软件系统也就会自然地被划分为 UI 界面，中间件系统，数据库。

微服务（microservice ）的划分方法不同，它倾向围绕业务功能的组织来分割服务。这些服务实现商业领域的软件，包括用户界面，持久化存储，任何的外部协作。因此，团队是跨职能的（cross-functional），包含开发过程所要求的所有技能：用户体验（user-experience）、数据库（database）和项目管理（project management）。

微服务（Microservice ）认为:团队应该负责产品的整个生命周期。理念是“谁构建，谁运维（you build, you run it）”，要求开发团队对软件产品的整个生命周期负责。这要求开发者每天都关注他们的软件运行如何，增加更用户的联系，同时承担一些售后支持。

微服务特点

强化终端及弱化通道

微服务倾向于做如下的选择：强化终端及弱化通道。微服务的应用致力松耦合和高内聚：采用单独的业务逻辑，表现的更像经典Unix意义上的过滤器一样，接受请求、处理业务逻辑、返回响应。它们更喜欢简单的REST风格，而不是复杂的协议，如WS或者BPEL或者集中式框架。
在整体工风格中，组件在进程内执行，进程间的消息通信通常通过调用方法或者回调函数。从整体式风格到微服务框架最大的问题在于通信方式的变更。从内存内部原始的调用变成远程调用，产生的大量的不可靠通信。因此，你需要把粗粒度的方法成更加细粒度的通信。

分散治理

分散数据管理

数据管理的分散化以许多不同的方式呈现，在抽象层，这意味着所有事物的概念模型将因系统而异。这带来的觉问题是大型的跨系统整合时，用户使用不同的系统将得到不同的信息。

微服务让每个服务管理自己的数据库：无论是相同数据库的不同实例，或者是不同的数据库系统。这种方法叫Polyglot Persistence。你可以把这种方法用在整体架构中，但是它更常见于微服务架构中。

自动部署

自动化部署技术在过去几年中得到了长足的发展：云计算，特别是AWS的发展，减少了构建、发布、运维微服务的复杂性。

如何构建微服务

每一个功能单元都是一个完整的功能单元。

spring cloud:分布式网络之间互相调用
spring cloud data flow流式数据计算、批处理

这篇关于微服务 个人理解+翻译的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！