微服务干货系列使用微服务架构之前，你必须知道的

Posted 2020-09-27 lytwajue

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了微服务干货系列使用微服务架构之前，你必须知道的相关的知识，希望对你有一定的参考价值。

正如敏捷之父MartinFowler所说的那样，单体架构和微服务并非简单的二选一，两者都是模糊的定义。这就意味着大多数系统都将在一个模糊的边界区域。非常多开发团队已经认识到微服务架构比单体架构更优越。可是也有其它团队感觉到这是一种消弱生产力的负担，就像不论什么软件架构，微服务架构相同有利弊。为了能做出一个明智的选择。你必须了解这些应用并将它们运用到你特定的环境中。

微服务的“定义”

假设须要准确的给微服务下一个定义，抱歉，笔者找了非常长时间，也没有一个准确的定义，最接近微服务的定义来自维基百科，全文例如以下：

In computing, microservices is a softwarearchitecture style in which complex applications are composedof small, independent processes communicating witheach other using language-agnostic APIs.These services are small,highlydecoupled and focus ondoing a small task, facilitatinga modular approach to system-building.

敏捷之父Martin Fowler的《Microservices》一文中给出的定义是这种：

In short, the microservice architectural style is an approach todeveloping a single application as a suite of small services, each running inits own process and communicating with lightweight mechanisms, often an HTTPresource API. These services are built around business capabilities andindependently deployable by fully automated deployment machinery. There is abare minimum of centralized management of these services, which may be writtenin different programming languages and use different data storage technologies.

综上。概括来说，微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每一个服务执行在自己的进程中，通过轻量的通讯机制联系。常常是基于HTTP资源API，这些服务基于业务能力构建。可以通过自己主动化部署方式独立部署，这些服务自己有一些小型集中化管理，可以是使用不同的编程语言编写。正如不同的数据存储技术一样。

好的，明确了微服务的“定义”之后，另一个须要知道的就是monolithic（总体）风格。

总体应用程序作为单一单元进行构建。企业级应用程序通常包括三个组成部分：一套client用户界面（由运行在用户设备上的浏览器中的html页面以及javascript代码构成）、一套后端数据库（将大量插入至数据库管理系统的大量表构成，通常採用关系数据库）以及一款server端应用程序。
该server端应用程序将负责处理HTTP请求、运行域逻辑、对来自数据库的数据进行检索与更新。同一时候选定HTML视图并将其发送至浏览器端。
此server端应用程序通常为单一的逻辑可运行文件。不论什么针对该系统的变更都须要对该server端应用程序进行新版本号构建与部署。

这种总体server机制在构建此类系统中可谓不可或缺。我们用于处理请求的所有逻辑都执行在单一进程其中，同意大家使用语言中的基本功能以将该应用程序拆分为类、函数以及命名空间。通过这种方式。我们可以在开发者的笔记本设备上执行并測试应用程序，同一时候利用一整套部署流程以确保所有变更都经过妥善測试而后被部署在生产环境其中。大家可以将大量实例执行在一套负载均衡方案之后，从而实现横向扩展能力。

这类总体应用程序当然可以切实起效，但人们却逐渐发现当中存在着诸多弊端——特别是在将大量应用程序部署在云环境当中的情况下。
因为变更周期被大量集中于一处——即使只指向应用程序中的一小部分。单一变更亦要求我们相应用程序总体进行重构与又一次部署。
随着时间推移。我们往往非常难保证理想的模块化结构，这意味着本应只影响单一模块的变更往往会扩散至该模块之外。
规模伸缩亦要求我们对总体应用程序进行规模调整，而非单纯为当中必要的部分进行资源扩容。

总体型应用程序与微服务架构应用程序

微服务的历史

“微服务”一词最早被威尼斯附近的一个软件架构师小组于2011年5月首次提及。当时他们用这个词汇来描写叙述自己最近研究项目其中所涉及的通用性架构机制。

2012年5月，该小组作出终于决议。觉得“微服务”是最适合的架构名称。

2012年3月。James在《微服务-Java以及Unix方式》其中就此发表了一篇案例研究报告，而Fred George也差点儿在同一时间进行了同样的工作。Netflix公司的Adrian Cockcroft将微服务架构称为“细化SOA”，并觉得这是一套在Web规模下具备开创意义的架构类型。Joe Walnes、Dan North、Evan Botcher以及Graham Tackley也分别在这篇文章中对此作出了评论。

微服务的特点

彼此独立：既然是一个独立的服务，那必定是一个完整的自治系统，不依赖外部的东西就行提供服务。
有自己一整套的完整的执行机制，有和外部通讯的标准化接口。
原子化：作为一个微服务。一定是一个原子化的服务。
也就是说服务不能再划分成更小的服务了。
世界上的一些事物都是有原子构成的。它为什么能构成全部的物体。正是因为它足够的基础。假设一个服务还能划分成几个小的服务。那我们就不能称之为一个微服务。它事实上能够通过几个微服务组合成的一个系统。
组合和重构：假设是最原子的服务，那一定是没有不论什么用处的。微服务之所以奇妙，在于它能高速的组合和重构。彼此组合成一个系统。系统里面全部的实体在概念上是对等的。因此它的结构相对简单化。是一种松散耦合的结构。这种系统，往往具有更强的可扩展性和鲁棒性。

知名微服务架构使用者

眼下据统计，知名的微服务架构使用者包含：

Akana
Amazon
AnyPresenceJustAPIs
Apprenda
Axway
1060 Research Ltd. has deployed architectures on its platform that contain on average between3-5,000 individual services since 2003.
Bluemix
Cloud Foundry
Google
The Guardian
Hailo Taxi
HP Helion Development Platform
Jelastic
Microsoft Azure
Netflix (Netflix receives nearlytwo-billion requests each day resulting in roughly 20 billion internal APIcalls.)
Nirmata
nearForm
Riot Games
SoundCloud
Uber
Joined Node

在此须要说的是。咱们好雨云在微服务领域也有非常多率先和独到的地方，在以后的【微服务干货系列】中，我们会慢慢分享给大家，敬请关注。

Docker在微服务系统中所扮演的角色

谈到微服务。不得不提到Docker，微服务要执行，首先须要一套执行的环境。

这套环境不能对外部有依赖性。同一时候。执行环境的粒度又必须足够的小，这样才干称之为”微“，否则必定是对资源的巨大浪费。Docker出现以后。我们看到了微服务的一个很完美的执行环境。

独立性：一个容器就是一个完整的运行环境。不依赖外部不论什么的东西。
细粒度：一台物理机器能够同一时候执行成百上千个容器。其计算粒度足够的小。
高速创建和销毁：容器能够在秒级进行创建和销毁，很适合服务的高速构建和重组。
完好的管理工具：数量众多的容器编排管理工具，可以高速的实现服务的组合和调度。

微服务领域的大牛

这里只提两位，一位是Martin Fowler。Martin Fowler是国际著名的面向对象分析设计、UML、模式等方面的专家，敏捷开发方法的创始人之中的一个，现为ThoughtWorks公司的首席科学家。他改变了人类开发软件的模式，他被开发人员们尊为“教父”。他的《Microservice》一文影响了非常多人。

技术分享