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

正如敏捷之父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（整体）风格。

 

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

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