微服务(microservices)

基于微服务的架构

2016-02-29  本文已影响388人  重度恐高症

介绍

本文是介绍如何实现完全自动化的持续部署系统的系列文章之一。想要了解整个系列内容请参考这篇文章

在本文中,我希望介绍什么才是一个真正的微服务。我还会列举一些用来决定是否应该使用微服务的原因。最后,我会简短概况一下使用基于微服务架构所产生的影响。

什么是微服务(micro service)?

很多开发人员第一眼看到这个词时,会被“微”这个字所误导。我们不应该按照字面意思来理解,顶多可以将微服务(简称MS)看做是一个比较小型的东西。

通常,微服务是一组逻辑上属于一体的相关功能集合。如果你熟悉领域驱动设计(domain driven design,缩写为DDD) ,可以将一个微服务想象成一个边界上下文(bound context)的实现。但这不是我们能够用来定义微服务的唯一方式。在现实中,你希望将一些功能封装成微服务的理由可能还包括以下几点:

微服务的特点

一旦我们确定了想要实现成微服务的功能,那么就需要确认我们的微服务是否具有以下几个特点:

由于按照定义,微服务是一个小型的服务,所以实现该微服务的代码量也应当尽量的少。这样,我们可以避免使用大型系统中的某些设计,来降低系统的复杂性。这些设计通常包括使用IoC框架或者像NHibernate或Entity Framework这样的ORM框架。

微服务的接口

微服务需要提供功能给外部系统访问。出于该原因,所有微服务都需要实现一组定义良好的接口。通常这些接口以RESTful API的形式提供,但是并不是仅此一种。其他一些接口类型还包括消息队列、tcp/ip或者udp实现的等等。由于一般应用系统的大多数微服务不会被公开暴露,所以我们可以选择最合适的协议或技术来实现,这样就不会让自己仅仅局限于RESTful API。更重要的是,微服务的接口应该永远保持稳定,并且是可按照版本管理的。

微服务示例

为了避免光谈一些微服务的抽象概念,我们举几个现实中适合于做成微服务的几个例子:

作者介绍

Gabriel N. Schenker最早的职业是一名物理学家。遵循内心对星球和宇宙的渴望和爱好,他选择了天体物理学作为博士研究方向。博士毕业之后,他很快将全部的精力都投入到了第二爱好——编写和设计软件架构。Gabriel已经工作了超过20年,主要从事.NET平台方面的顾问、软件架构师、培训师等工作。他现在是德克萨斯州奥斯汀ClearMeasure公司的首席软件架构师。Gabriel热衷于软件开发,并且希望能够通过提供一些开发原则和框架来提高开发效率。如今Gabriel已经成家并且是四个孩子的父亲,在工作之余他喜欢在山脉间徒步旅行、做饭和阅读。

原文发表于这里

欢迎打赏(微信请点击“阅读原文”),也请关注微信公众账号“重度恐高症”,精彩技术文章就在这里。

上一篇下一篇

猜你喜欢

热点阅读