微服务和微处理器

一、关于被混淆的微服务

       关于微服务这个名词， 成为混淆之源的速度甚至比它的使用成为炒作还要快。不知何时起，它已经成为软件领域服务架构的趋势，甚至可能成为事实上的标准。

      从设计用途看，微服务不应该由预先确定的大小指标来定义，而应该由实现某个目的的必要性来定义。遵循一个目的会导致有用的凝聚力。

       无论是模块、插件、组件、本地还是分布式， 软件的每个部分都在架构中占有一席之地。在这里，我将所有这些模块、插件和组件都称为服务，以保持讨论的主题。

     面向服务的设计思想总结：给定的服务可以大到它所需要的大小，但不会更大。

     面向服务建模的时候，总能简单的抽象为： 实体即服务， 这是一种实现单一软件模型概念的服务，仅此而已。建模的概念实际上可能不是实体。它可能是某种计算器或其他类型的处理器，但假设它是您通常认为是一个对象代表同一运行时进程/实例中的另一个对象做某事的任何东西。在这种情况下，两个对象之间没有网络，因为在那里放置网络边界实际上是浪费；也就是说，除非网络边界是目的而不是手段

二、从计算机硬件体系的微处理器到微服务

       微处理器是计算机用来完成其工作的电子元件。它是单个集成电路芯片上的中央处理单元，包含数百万个非常小的组件，包括协同工作的晶体管、电阻器和二极管……
      微处理器按其数据总线或地址总线的大小分类。它们也分为 CISC 和 RISC 类型。 有一个大小分类可以帮助确定中央处理单元 (CPU) 是否被视为微处理器：它们的数据总线或地址总线的大小。然而，正如您将看到的，它不是一个非常激进或教条的定义，例如，它根据功率来判断 CPU 的价值。有速度极快且功能强大的微处理器，也有速度非常慢且功耗低的微处理器。无论是哪种微处理器，每个微处理器都有自己的目的和工作要做。它们都是微处理器。

三、专门构建的微服务

          每一个微服务都有自己的目的和工作要做。微服务在一组运行时约束和 SLA 中发挥作用。

四、从有界上下文作为微服务开始

       使用领域驱动设计 (DDD) 有界上下文作为微服务的初始“度量”是一个很好的起点。有界上下文的大小不是任意的。 有界上下文是编码在域模型中的通用语言的大小，并具有用于 UI 和/或 REST 端点、数据库访问和可能的消息传递机制的支持组件. 这里的关键是无处不在的语言。无处不在的语言是由一个或多个业务专家和开发人员组成的团队开发的。 从有界上下文作为微服务开始，专注于单一的核心业务价值。