微服务架构的设计理念

1、微服务

微服务是单独解决某一项任务，提供对应服务的一个应用，可以看作IDEA中的一个个项目工程，或者模块。

1. 为了完成某项业务而开发的模块，一个模块只做一件事。
2. 该模块由独立的数据库，代码，甚至是语言，达到最大程度上的解藕。

2、微服务架构

微服务架构是最近非常流行的一种架构模式，由Martin fowler 于2014年提出，微服务的架构理念是，由多个可独立部署的服务进行软件设计。

设计理念

1. 提供单一职责服务，每个项目是由多个服务组成

2.  围绕业务功能组建开发团队

        我们对微服务项目团队的定义， 一般是遵循亚马逊“2个披萨”原则，即一个项目团队可以被2个披萨喂饱， 最好不超过12人，有的小型项目，一个人可以负责一个微服务。

        团队应该围绕业务功能组建，传统项目功能拆分，是将一个项目按技术层面拆分，界面拆分给前端开发，数据库拆分给数据库团队，应用服务器拆分给后台团队等。在微服务架构下， 项目拆分是按照业务来拆分，一个团队负责整条业务线，因此，微服务的团队应该是跨职能的，如果一个人担任一个微服务开发，那他至少能负责前端、数据库、后台的开发，也就是全栈开发。

     3. 团队负责整个服务生命周期

        在传统项目管理中，一个项目被交付后，项目就算完工了，一旦被认为项目完工，项目组就被解散。

        在微服务的项目管理中，采纳一个团队在整个产品的生命周期中都对其拥有的理念，这一点来自于亚马逊的“谁构建，谁治理”的理念。一个开发团队要对项目在生产环境下的运行负责，他们会关注项目是如何在生产环境下运行的，增进与用户的联系。

    4. 服务间通信

        各个服务间的通信是通过一个轻量级的消息总线来进行消息发送。此时所选择的基础设施，像RabbitMQ或ZeroMQ那样的简单框架，即除了提供可靠的异步机制以外不做其他任何事情，智能功能存在于各个端点中，即存在于各个服务中。

        在一个单块系统中，各个组件在同一个进程中运行。它们相互之间的通信，要么通过方法调用，要么通过函数调用来进行。将一个单块系统改造为若干微服务的最大问题，在于对通信模式的改变。仅仅将内存中的方法调用转换为RPC调用，会导致微服务之间产生繁琐的通信，使得系统表现变糟。取而代之的是，需要用更粗粒度的协议来替代细粒度的服务间通信。

     5. 去中心化的技术管理

       使用传统的中心化方式来进行技术管理，会产生的一个后果是，趋向于在单一技术平台上制定标准。经验表明，这种做法会带来局限性。我们更喜欢根据工作的不同来选用合理的开发工具。尽管那些单个应用系统能在一定程度上使用了不同的编程语言。

       如果能将单个应用程序拆分成多个服务，那么在构建每个服务时，就可以选择不同的技术栈。比如可以用Node.Js写一个简单报表页面，或者用C++来做一套高性能组件，都没有问题。还可以换一种不同风格的数据库，来更好地适应一个组件的读取数据的行为。   

     6. 去中心化的数据管理

        微服务的去中心化数据存储决策。虽然单体应用程序更喜欢单一的逻辑数据库做持久化存储，但企业往往倾向于一系列应用程序共用一个单一的数据库 - 这些决定是供应商授权许可的商业模式驱动的。微服务更倾向于让每个服务管理自己的数据库，或者同一数据库技术的不同实例，或完全不同的数据库系统 - 这就是所谓的混合持久化(Polyglot Persistence)。你可以在单体应用程序中使用混合持久化，但它更常出现在为服务里。

       

     7. 基础设施自动化

        基础设施自动化技术在过去几年里已经得到长足的发展。云的演进，特别是AWS的发展，已经降低了构建、部署和运维微服务的操作复杂性。

        许多使用微服务构建的产品和系统，正在被这样的团队所构建，即他们都具备极其丰富的“持续交付”和其前身“持续集成”的经验。用这种方法构建软件的各个团队，广泛采用了基础设施的自动化技术。如下图的构建流水线所示：

     8. 容错式设计

        使用各个微服务来替代组件，其结果是各个应用程序需要被设计的能够容忍这些服务所出现的故障。如果服务提供方失效，那么任何对该服务的调用都会出现故障。客户端要尽可能提前应对对这种情况。与一个单块设计相比，这是一个微服务架构的一种劣势。因为在处理这种情况时会引入额外的复杂度。为此，各个微服务团队在不断地反思：这些服务故障是如何影响用户体验的。Netflix公司所研发的开源测试工具Simian Army，能够诱导服务发生故障，甚至能诱导一个数据中心在工作日发生故障，来测试该应用的弹性和监控能力。   

      9. 演进式设计

       强调“可更换性”的特点，是模块化设计一般性原则的一个特例，通过“变化模式”（pattern of change）来驱动模块化的实现。大家都愿意将那些能在同时发生变化的东西，放到同一个模块中。系统中那些很少发生变化的部分，应该被放到不同的服务中，以区别于那些正在经历大量变动(churn)的部分。当发现两个服务需要被同时、反复变更，就意味着它们两个需要被合并。

       把一个个组件放入一个个服务中，提高了软件发布精细化的程度。对于一个单块系统，任何变化都需要做一次整个应用系统的全量构建和部署。然而，对于一个个微服务来说，只需要重新部署修改过的那些服务就够了。这能简化并加快发布过程。但缺点是：必须要考虑当一个服务发生变化时，依赖它并对其进行消费的其他服务将无法工作。传统的集成方法是使用版本化来解决这个问题。但在微服务世界中，大家更喜欢将版本化作为最后万不得已的手段来使用。我们可以通过下述方法来避免许多版本化的工作，即把各个服务设计得尽量能够容错，来应对其所依赖的服务所发生的变化。