微服务(Microservices)是业界最近的流行语,每个人好像都在以这样或那样的方式谈论它。现在让我们理解什么是微服务?在本篇教程中,我们会试着理解微服务的定义、概念以及原则。
今天,微服务是SOA(面向服务的架构体系)之后日趋流行的架构体系之一。如果你紧跟业界趋势,你会发现商业机构不再像几年前那样开发大型应用来管理它们的端对端业务功能,而是选择那些快速而且敏捷的应用,这样可以花费更少的成本。
微服务有助于打破大型应用的局限并且可以在系统里面构建逻辑独立的更小的系统。比如说,通过使用Amazon AWS,你可以毫不费力地构建一个云应用。这是一个说明微服务能干什么事情的非常好的例子。
在上图你可以看到,每个微服务有它自己的业务层和数据库。这样设计的话,一个微服务的改变将不会影响到其它服务。
通常情况,微服务通过使用被广泛接受的轻量协议来交互,比如HTTP和REST,或者消息协议,比如JMS(Java Message Service)或者AMQP(Advanced Message Queuing Protocol)。在某些特定的场景,开发者也可以使用更多的特殊协议。
现在让我们检查微服务“必须拥有”(must have)的原则。
单一职责原则是SOLID design pattern其中原则之一。它表示一个单元、一个类、一个函数或者一个微服务有且只有唯一指责。
在任何时候,一个微服务都不应该拥有多个指责。
微服务应该注重特定的业务功能并且保证它能够解决问题。一个微服务永远也不应该限制它选择合适的技术栈或者最适合解决业务目标的后端数据库。
为了解决许多业务问题,在某些方面需要做出一些妥协,这通常是我们设计单体应用的约束和限制。微服务能够让你在解决手头上问题的时候选择最优方案。
另一个这种设计的重要方面与开发前后的责任相关。在大型组织当中,通常一个团队开发完应用,在一些知识交接过后,就会把它交给运维团队。然而在微服务当中,开发团队不仅仅是开发应用——拥有它,并且对它未来的运维负责。
You build it,you own it!
这样会使开发者与他们软件的日常运维接触,并且对他们是怎么构建被用户在真实世界中使用的产品有更好的理解。
准备和建设微服务的基础设施是另外一个十分重要的需求。一个服务应该是可独立部署的并且拥有所有的依赖,包括库依赖,甚至是像web服务器、容器或或者抽象化物理资源的虚拟机。
一个微服务和SOA的主要区别之一在于它们的自治级别。大多数的SOA实现提供了服务级别的抽象,然而微服务则更加深入,它抽象了环境的实现和执行。
在传统的应用开发中,我们构建一个WAR或者EAR,然后将它部署到JEE应用服务器,比如JBoss、WebLogic和WebSphere等等。我们也许会部署多个应用到同一个JEE容器。在微服务架构的理想条件下,每个微服务被构建成一个fat Jar,嵌入所有的依赖并且以一个独立的Java进程运行。
在设计一个微服务时,我们应该把各种失败的可能性放在心上。我们应该经常问自己,如果服务有时候失效了或者宕机了怎么办?这些是非常重要的问题,并且我们需在开始实际编码前解决它们——准确评估服务失效会多大程度地影响用户体验。
Fail fast(快速失败)是另外一个用来构建可容错性、弹性系统的概念。这种哲学倡导构建可能出错的系统,而不是永不出错的系统。由于服务可能在任何时间失效,所以能够快速检测出失效非常重要。当然如果可以的话,最好还能够让服务自动恢复。
微服务着重于应用的实时监控,用于检查系统元素(比如数据库每秒收到多少个请求)和业务相关指标(比如每秒收到多个订单)。语义监控可以提供一个检测错误的告警系统,来让开发团队及时跟进以及查明错误。
相比传统的多层级单体架构,微服务提供了许多的好处。让我们把它们列出来: