《Spring微服务实战》读书笔记——构建微服务

设计微服务架构

构建代码的脚手架

分解业务问题

• 描述业务问题，安装名词来描述问题
• 注意动词
• 寻找数据内聚性

肯定服务粒度

使用数据模型做为将单体应用分解到微服务的基础。

能够经过下面的概念来肯定正确的服务粒度：

• 普遍的使用微服务和重构为更小的服务
• 关注你的服务如何与其余服务交互
• 随着你对问题领域的理解不断增加，服务职责将不断变化

感觉很差的微服务设计
服务粒度太粗：

• 服务具备太多的职责
• 服务经过大量的表管理数据
• 测试用例过多

服务粒度太细：

• 在部分问题领域有太多微服务
• 微服务彼此严重依赖
• 微服务组成一个简单的CRUD服务集

微服务应该负责一种业务逻辑

定义服务接口

/** * @RequestMapping 暴露Controller的根URL * {organizationId}是一个占位符，表示URL在每次调用会传递一个organizationId参数 */
@RestController
@RequestMapping(value = "/v1/organizations/{organizationId}/licenses")
public class LicenseServiceController {

    /** * @RequestMapping( * method = {RequestMethod.GET} * ) * * * @param organizationId 经过@PathVariable来访问 * @param licenseId * @return */
    @GetMapping(value="/{licenseId}")
    public License getLicenses(
            @PathVariable("organizationId") String organizationId,
            @PathVariable("licenseId") String licenseId) {
        return  License.builder()
                .id(licenseId)
                .productName("Teleco")
                .licenseType("Seat")
                .organizationId(organizationId)
                .build();
    }
}

端点的名称问题

微服务的URL应该能清楚的表达服务的目的，尽可能使用下面的准则：

• 使用明确的URL名称创建服务所表明的资源
• 为URL创建早起版本控制方案
  URL 及其相应端点表示服务全部者和服务消费者之间的契约。一个常见的模式是在全部端点前使用一个版本号。及早创建你的版本控制计划并坚持下去。在已经有好几个用户使用它们以后，为 URL 升级版本是很是困难的。

微服务开发的四项原则

• 微服务应该是独立和单独可部署的，多个服务实例做为单独的软件构件启动和中止。
• 微服务是可配置的，当服务实例启动时，它应该从配置中心读取所需的数据来配置本身，或将其配置信息传递为环境变量。配置服务不须要认为干预
• 微服务实例须要对客户端透明
• 微服务应该显示其健康情况

示例图

构建微服务应用的十二要素

基准代码

全部应用程序代码和服务器配置信息都应处于版本控制中。每一个微服务在源码控制系统内有本身独立的代码库。

依赖

经过使用构建工具如 Maven（java）显式声明你的应用程序的依赖。第三方 JAR 依
赖性应该使用其特定版本号声明。这容许你的微服务老是使用相同版本的 lib 库进行构建

配置

独立于代码存储应用程序配置。你的应用程序配置不该该与源代码在同一个存储库中

后端服务

你的微服务每每会经过网络与一个数据库或消息系统迚行通讯。当它这样作时，
你应该确保在任什么时候候，你均可以将数据库的实现从内部管理的服务转换为第三方服务。

构建，发布，运行

将你的构建，发布，和运行部署的应用程序各部分彻底分离。一旦代码
被构建，开发人员就永远不该该在运行时对代码进行更改。 任何修改都须要从新执行构建
过程和从新部署。构建的服务是不可变的，不能更改。

进程

你的微服务应该是无状态的。它们在任什么时候候均可以被杀死和取代，而没必要惧怕一个受损的服务实例将致使数据丢失。

端口绑定

一个微服务对服务的运行时引擎（打包在服务的可执行文件）是彻底独立的。
你将能运行该服务而不须要分离的 Web 或应用服务器。服务应该在命令行中独立启动，并经过暴露的 HTTP 端口当即被访问。

并发

当须要进行伸缩时，不要依赖于单个服务中的线程模型。相反，加载更多的微服务
实例和在水平方向扩展。这并不排除在你的微服务使用线程，但别期望把它做为你伸缩的惟一途径。规模扩大，而不是上升。

通用性

微服务是一次性的，一经要求就能够启动和中止。启动时间应尽可能减小，当接收到
操做系统的一个终止信号时，进程应该优雅地关闭

开发环境不线上环境等价

最小化服务运行的全部环境之间的差距（包括开发人员的桌面）。
开发人员应该在本地使用与实际服务将运行的相同的基础设施来进行服务开发。它还意味着服务在环境之间部署的时间应该是几个小时，而不是几个星期。一旦代码被提交，它应该已经被测试和从开发一直到生产尽快升级。

日志

日志是一个事件流。一旦日志被输出，它们对工具将是可流化的，如 Splunk或Fluentd ，它们将聚合日志并将其写入到中心存储设备。微服务不该该关心这项技术是如何出现的，当日志正在被输出的时候，开发人员应该在视觉上经过 STDOUT看日志。

管理进程

开发人员经常不得不针对他们的服务（数据迁移或转换）执行管理任务。 这些任 务不该该是临时的，而应该经过源代码存储库管理和维护的脚原本完成。这些脚本应该是可重复的，而且在它们运行的每一个环境中都不改变（在每一个环境中都不修改脚本代码）。