微服务-定义、原则和优点

原文：http://howtodoinjava.com/design-patterns/microservices-definition-principles-benefits/

本文是原作者阅读多个关于微服务的资料后的总结，翻译时尽量保持原文含义。

在各个公司，“微服务”是最流行的词，貌似大家对这个词都能多少说点。

无论如何，让我们理解下，啥叫“微服务”？在这篇文章里，我尝试理解下微服务的定义，概念及其相关的原则。

主要内容：

1. 微服务的定义

2. 微服务的原则

3. 微服务的优点

4. 总结

微服务的定义

现在，微服务是继SOA(面向服务的软件架构)之后的越来越流行的架构模式。

如果你比较关注行业动态，那你会意识到，现在的企业已经不再像很多年之前那样对开发一个大型的应用程序来管理他们的业务流程感兴趣，

而是倾向于选择那些省钱的能快速并且敏捷构建的应用程序。

微服务有助于打破大型应用程序的边界，而是构建多个业务独立的的小系统。。比如，用亚马逊云(AWS)，你可以简便的构建一个云应用。

这是一个很好的微服务的例子。

如上图，每个微服务都有自己的业务层和数据库，这样做，改变其中一个微服务，不会影响其他的。

一般来说，微服务之间的沟通使用那些被广泛应用的轻量级的协议，比如REST和HTTP，或者是消息协议，比如JMS或AMOP。特殊场景下，也可以使用特定协议。

微服务的原则

现在我们来看下一个微服务应该具有的原则

1.单一职责原则

单一职责原则是5个设计原则中（ SOLID design pattern .）的一个，它表明：一个单元（一个类、函数或者微服务）应该有且只有一个职责。

无论如何，一个微服务不应该包含多于一个的职责。

2.围绕业务构建微服务

微服务应当聚焦于某一特定的业务功能，并且确保完成它。

从技术上，微服务不应该局限于某个技术栈或者后端存储，可以非常灵活，以便于解决业务问题。

这一点在非微服务的系统设计时，可能导致我们做一些妥协。而微服务可以让你用你认为最合适的方式解决。

3.谁创建，谁负责

这一点是关于软件开发前后责任归属的观点。在一个大型公司，通常开发团队开发完成之后，通过一些交接会议将应用交接给维护团队，

在微服务里，创建微服务的团队有责任继续维护它。

You build it, you own it !!

这种方式让开发团队可以每天操作软件，并且更好的理解，客户是如何使用软件的。

4.基础设施自动化

盛载微服务准备和构建的基础设施也是一个非常重要的需求。

一个服务应当被独立部署，并且包含所有的依赖，环境等的物理资源。

SOA和微服务的一个主要不同点就是自动化程度上的不同。大部分的SOA实现只达到服务级别的抽象，而微服务走的更远，它达到了对实现和运行环境的抽象级别。

也就是说，在传统的开发中，我们构建一个WAR包或EAR包，然后把他们部署在容器上。

而在一个规范的微服务中，每个微服务应该被构建成胖jar（ fat Jar）其中内置了所有的依赖，然后作为一个单独的java进程存在。

5.设计考虑了失效(Failure)

待续

微服务的优点

总结