前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >【微服务干货系列】使用微服务架构之前,你必须知道的

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

作者头像
Rainbond开源
发布2018-05-31 10:48:14
3070
发布2018-05-31 10:48:14
举报

正如敏捷之父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视图并将其发送至浏览器端。此服务器端应用程序通常为单一的逻辑可执行文件。任何针对该系统的变更都需要对该服务器端应用程序进行新版本构建与部署。 这样的整体服务器机制在构建此类系统中可谓不可或缺。我们用于处理请求的全部逻辑都运行在单一进程当中,允许大家使用语言中的基本功能以将该应用程序拆分为类、函数以及命名空间。通过这种方式,我们能够在开发人员的笔记本设备上运行并测试应用程序,同时利用一整套部署流程以确保全部变更都经过妥善测试而后被部署在生产环境当中。大家可以将大量实例运行在一套负载均衡方案之后,从而实现横向扩展能力。 这类整体应用程序当然能够切实起效,但人们却逐渐发现其中存在着诸多弊端——特别是在将大量应用程序部署在云环境当中的情况下。由于变更周期被大量集中于一处——即使仅仅指向应用程序中的一小部分,单一变更亦要求我们对应用程序整体进行重构与重新部署。随着时间推移,我们往往很难保证理想的模块化结构,这意味着本应只影响单一模块的变更往往会扩散至该模块之外。规模伸缩亦要求我们对整体应用程序进行规模调整,而非单纯为其中必要的部分进行资源扩容。

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

微服务的历史

“微服务”一词最早被威尼斯附近的一个软件架构师小组于2011年5月首次提及,当时他们用这个词汇来描述自己近期研究项目当中所涉及的通用性架构机制。2012年5月,该小组作出最终决议,认为“微服务”是最适合的架构名称。2012年3月,James在《微服务-Java以及Unix方式》当中就此发表了一篇案例研究报告,而Fred George也几乎在同一时间进行了相同的工作。Netflix公司的Adrian Cockcroft将微服务架构称为“细化SOA”,并认为这是一套在Web规模下具备开创意义的架构类型。Joe Walnes、Dan North、Evan Botcher以及Graham Tackley也分别在这篇文章中对此作出了评论。

微服务的特点

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

知名微服务架构使用者

目前据统计,知名的微服务架构使用者包括:

  • 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》一文影响了很多人。

另外一位是《Building Microservice》作者Sam Newman,他也是ThoughtWorks的技术专家,他的这本著作可以说是学习微服务开发者必读之物。

学习微服务资料整理

上文提到的Martin Fowle 《Microservices》一文,国内已经有很多翻译了,具体可以点击下面链接:

http://blog.csdn.net/wurenhai/article/details/37659335

在Docker上运行微服务

http://www.infoq.com/cn/news/2015/06/qiniu-best531?utm_campaign=infoq_content&

微服务架构在云端的应用

http://www.csdn.net/article/2015-11-16/2826222

再谈Docker,微服务的场景化应用

http://www.d1net.com/cloud/tech/360510.html

Martin Folwer谈微服务的优缺点

http://www.wtoutiao.com/p/i648ov.html

Sam Newman 《Building Microservice》下载地址

http://download.csdn.net/detail/ramissue/8441997

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2016-02-22,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 Rainbond 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 好的,明白了微服务的“定义”之后,还有一个需要知道的就是monolithic(整体)风格。
  • 整体应用程序作为单一单元进行构建。企业级应用程序通常包含三个组成部分:一套客户端用户界面(由运行在用户设备上的浏览器中的HTML页面以及JavaScript代码构成)、一套后端数据库(将大量插入至数据库管理系统的大量表构成,通常采用关系数据库)以及一款服务器端应用程序。该服务器端应用程序将负责处理HTTP请求、执行域逻辑、对来自数据库的数据进行检索与更新,同时选定HTML视图并将其发送至浏览器端。此服务器端应用程序通常为单一的逻辑可执行文件。任何针对该系统的变更都需要对该服务器端应用程序进行新版本构建与部署。 这样的整体服务器机制在构建此类系统中可谓不可或缺。我们用于处理请求的全部逻辑都运行在单一进程当中,允许大家使用语言中的基本功能以将该应用程序拆分为类、函数以及命名空间。通过这种方式,我们能够在开发人员的笔记本设备上运行并测试应用程序,同时利用一整套部署流程以确保全部变更都经过妥善测试而后被部署在生产环境当中。大家可以将大量实例运行在一套负载均衡方案之后,从而实现横向扩展能力。 这类整体应用程序当然能够切实起效,但人们却逐渐发现其中存在着诸多弊端——特别是在将大量应用程序部署在云环境当中的情况下。由于变更周期被大量集中于一处——即使仅仅指向应用程序中的一小部分,单一变更亦要求我们对应用程序整体进行重构与重新部署。随着时间推移,我们往往很难保证理想的模块化结构,这意味着本应只影响单一模块的变更往往会扩散至该模块之外。规模伸缩亦要求我们对整体应用程序进行规模调整,而非单纯为其中必要的部分进行资源扩容。
  • 整体型应用程序与微服务架构应用程序
相关产品与服务
容器服务
腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档