对“用微服务架构开发应用”的注解

下文是对 Chris Richardson（CloudFoundry 的创建者） 在 SlideShare 分享的“Developing applications with a microservice architecture”（需要科学上网，不会的同学学习吧，为了你们好，此处不发表评论）的注解。

在全球最大的视频网站上也有 Chris Richardson 的演讲的视频，自己找吧。我还没来及看，而且我也是普通码农一个，所以下面的内容难免有一些谬误，但技术胜在交流，所以下发表出来。以后我必定会做更新。

P5 The (sometimes evil) monolith

讲 Monolithic（单一的）应用程序的缺点：

  1. 妨碍频繁部署
  2. 使你的开发环境负担过重
  3. 妨碍开发效率
  4. 妨碍技术栈的升级

P14 Decomposing applications into services

P16 The scale cube

影响伸缩性的三点

  1. 功能分解
  2. 数据分区
  3. 横向复制（什么意思？）

P20 Service deployment options 服务部署选项

  • 虚机
  • Docker 类容器
  • JVM
  • JAR、OSGi Bundle
    越向上隔离度越高，效率越低，向下则相反

P22 服务划分的策略

  • 按名词划分
  • 按动词划分
  • 单一原则
  • Unix 风格：就像是 Unix 系统一样，有无数小命令组成，每个命令只关注自己的一小块功能。但这种风格更适合像 Unix 系统规模一样的大系统

服务划分的太少和太多都不好，所以，这是一门艺术。划分服务的目的是让开发和部署更容易，而不能为了服务而服务。

P30 eliminates long-term commitment to a single technology stack

构建模块化、多语言、多框架的应用
注：主要是说 Microservices 有这样的能力，让你能够选择合适的语言和框架完成工作。同样，不能为了语言而语言，为了框架而框架

P31 Two levels of architecture 架构的两个层次

  1. 系统层：以 service 为单元。服务直接的接口和通信机制应该相对稳定
  2. 服务层：每个服务内部可以使用不同的框架，合适的工具，快速演化

P33 但是也有一系列的缺点

P40 什么时候采用微服务

  • 一开始你不需要，如果一开始就采用微服务，那你开发起来会较慢
  • 到后来，你将需要微服务，如果你很晚才使用微服务，那重构起来会很痛苦

P41 客户端与服务的通信设计

举个栗子

P43 如果前端直接和后端通信

会产生各种不正式的 API，同时还有对 Web 不友好的协议，比如 AMQP。解决方法是引入 API Gateway

P46 Netflix API Gateway 的设计

没看懂，详细看这里 http://techblog.netflix.com/2013/01/optimizing-netflix-api.html

P47 API Gateway 设计的挑战

当然是对于大型网站来说，挑战很大

P51 浏览器访问多服务的挑战

不再能通过单一的 URL 访问服务了，如何解决？可以用类似与 HAProxy 的技术

P52 服务之间如何通信

有同步的 HTTP，也有异步 AMQP。有流行的 JSON，也有像 Thrift 的那样的二级制协议（当然更有效率。基于 TCP）

接下来揭晓消息和 HTTP 分别作为通信机制的优缺点

P56 另一个挑战：服务发现

选项1：负载均衡器。负载均衡器负责定位服务，接受服务的注册。亚马逊采用这种方式
选项2：客户端自己搞定：架构中只有一个服务注册中心。服务提供者向注册中心注册，客户端则向注册中心查找可用的服务，直接调用。Netflix 采用这种方式。

这两种方式均有链接做详细解释。

P58 Lots of moving parts

Content router 和 API Gateway 的不同。前者在整个系统（机房）之外，可能会包含如 CDN 的功能。后者是系统的一部分

P59 Decentralized data management 去中心化的数据管理

P60 解构服务便意味着解构数据库便意味着更少的耦合

P61 更多样的存储

P62 那数据之间的关联该怎么办

比如订单服务中的订单（表）和客户服务中的客户（表）存在着多对一的关系，那解构的服务和解构的数据如何处理它们之间的管理关系呢？

P63 更多的问题

  • 服务A需要读取服务B拥有的数据，肿么办
  • 跨服务的事务肿么办？

P65 对于第一个读数据的问题的解决方法一

通过 API 来实现，我们成这个方法是“拉”数据（呃。。。）。好处是实现简单，毕竟调用一下 API 就好了；保证数据是新鲜的（不会有脏数据的问题）
缺点：降低可用性（依赖于服务），增加相应时间

P66 方法二

复制表：在订单服务中也有一个客户表（Customer‘），这个表是客户服务中的 Customer 表的一个复制，但是只包含订单系统所关心的信用额度的数据。同时，订单服务需要提供一个 API 去使得其 Customer‘ 的数据能和客户服务的数据同步

这种方法采用的 DDD 中的有界上下文的设计思想，详见领域驱动设计 Domain Driven Design

这种方法的好处是更好的可用性（不用依赖其它服务）、更好的延迟；缺点是额外的数据复制和同步的复杂度。

我只能说，信用额度这种和钱有关的一旦不同步就不好了啊。所以低延迟高可用的消息队列很重要，比如 Kafka

P69 如何更新和复制分布式的数据呢

P70 分布式事务（比如 JTA）

不说了，总之互联网很少用

P71 事件驱动

只能保证最终一致（前提是消息队列靠谱）
互联网更多的是采用这种方法，所以经常能听到淘宝说它的消息队列多么多么牛Ｘ。一般来说一般的用 RabbitMQ，吞吐更大的用 Kafka。再满足不了需求的就自己搞。其实淘宝的 MetaQ也是抄的Kafka，只是前者用Java，后者用 Scala。再多说点 RabbitMQ 用的是 Erlang。所以如果想再学一门 Java 以外的服务器端开发语言，Scala、Erlang、Go 里面挑一个

说的简单，其实这事件驱动的架构不好设计

P79 Using event sourcing

那用事件驱动如何解决前面的那个栗子呢？看图

API 和事件驱动这两种方法谈不上谁好谁坏

P80 Custemer aggregate 和 EventSource API

都是 Scala 的代码

P86 后面是一个实战

PS. 开源中国博客的标题怎么限制字数限制的这么狠

时间： 2024-08-02 11:04:58

对“用微服务架构开发应用”的注解的相关文章

从 Spring Cloud 开始，聊聊微服务架构实践之路

[编者的话]随着公司业务量的飞速发展,平台面临的挑战已经远远大于业务,需求量不断增加,技术人员数量增加,面临的复杂度也大大增加.在这个背景下,平台的技术架构也完成了从传统的单体应用到微服务化的演进. 系统架构的演进过程 单一应用架构(第一代架构) 这是平台最开始的情况,当时流量小,为了节约成本,并将所有应用都打包放到一个应用里面,采用的架构为 .NET SQL Server: 表示层:位于最外层(最上层),最接近用户.用于显示数据和接收用户输入的数 据,为用户提供一种交互式操作的界面,平台所使用

基于docker部署的微服务架构（四）： 配置中心

原文:http://www.jianshu.com/p/b17d65934b58%20 前言 在微服务架构中,由于服务数量众多,如果使用传统的配置文件管理方式,配置文件分散在各个项目中,不易于集中管理和维护.在 spring cloud 中使用 config-server 集中管理配置文件,可以使用 git.svn.本地资源目录 来管理配置文件,在集成了 spring cloud bus 之后还可以通过一条 post 请求,让所有连接到消息总线的服务,重新从config-server 拉取配置文

Spring Cloud构建微服务架构（五）服务网关

通过之前几篇Spring Cloud中几个核心组件的介绍,我们已经可以构建一个简略的(不够完善)微服务架构了.比如下图所示: alt 我们使用Spring Cloud Netflix中的Eureka实现了服务注册中心以及服务注册与发现:而服务间通过Ribbon或Feign实现服务的消费以及均衡负载:通过Spring Cloud Config实现了应用多环境的外部化配置以及版本管理.为了使得服务集群更为健壮,使用Hystrix的融断机制来避免在微服务架构中个别服务出现异常时引起的故障蔓延. 在该架

微服务架构介绍

jhipser微服务架构介绍 内容提要 本文涉及以下内容: 微服务架构介绍 spring cloud介绍 jhipster架构介绍 微服务架构介绍 微服务概念 微服务和SOA很相似,都是按照业务功能把系统拆分成一个一个的服务.比如电子商务系统拆分成订单服务,商品服务等,每个微服务都是自治的,可以单独部署.微服务和SOA的区别是:微服务粒度更细,通信协议倾向于使用restfull api 而不使用webservice.微服务有很多优点,包括松散耦合.自治服务.分散化治理以及易于持续交付等等.微服务

微服务架构实践 - 你只懂docker与spring boot就够了吗？

微服务架构实践 - 你只懂docker与spring boot就够了吗? 作者 浮云发发 已关注 2017.02.27 02:50* 字数 2613 阅读 2583评论 6喜欢 35赞赏 2 微服务并不是单独存在的,为了更好地实现微服务架构,需要整合许多组件混搭使用,方能打通任督二脉,天下无敌.网上很多大拿讲了微服务治理的内容,也有人单方面讲微服务的,比如spring boot与docker,本文着重于组件选型的较量,也积累了我们团队多次PK的精华:这些组件包括spring boot.sprin

Spring Cloud构建微服务架构（一）——服务注册与发现

Spring Cloud简介 Spring Cloud是一个基于Spring Boot实现的云应用开发工具,它为基于JVM的云应用开发中的配置管理.服务发现.断路器.智能路由.微代理.控制总线.全局锁.决策竞选.分布式会话和集群状态管理等操作提供了一种简单的开发方式. Spring Cloud包含了多个子项目(针对分布式系统中涉及的多个不同开源产品),比如:Spring Cloud Config.Spring Cloud Netflix.Spring Cloud CloudFoundry.Spr

Spring Cloud构建微服务架构（一）服务注册与发现

原文来源:http://blog.didispace.com/springcloud1/ Spring Cloud简介 Spring Cloud是一个基于Spring Boot实现的云应用开发工具,它为基于JVM的云应用开发中的配置管理.服务发现.断路器.智能路由.微代理.控制总线.全局锁.决策竞选.分布式会话和集群状态管理等操作提供了一种简单的开发方式. Spring Cloud包含了多个子项目(针对分布式系统中涉及的多个不同开源产品),比如:Spring Cloud Config.Sprin

Spring Cloud构建微服务架构分布式配置中心

Spring Cloud Config是Spring Cloud团队创建的一个全新项目,用来为分布式系统中的基础设施和微服务应用提供集中化的外部配置支持,它分为服务端与客户端两个部分.其中服务端也称为分布式配置中心,它是一个独立的微服务应用,用来连接配置仓库并为客户端提供获取配置信息.加密/解密信息等访问接口:而客户端则是微服务架构中的各个微服务应用或基础设施,它们通过指定的配置中心来管理应用资源与业务相关的配置内容,并在启动的时候从配置中心获取和加载配置信息.Spring Cloud Conf

构建微服务架构Spring Cloud：服务注册与发现（Eureka、Consul）

Spring Cloud简介 Spring Cloud是一个基于Spring Boot实现的云应用开发工具,它为基于JVM的云应用开发中涉及的配置管理.服务发现.断路器.智能路由.微代理.控制总线.全局锁.决策竞选.分布式会话和集群状态管理等操作提供了一种简单的开发方式. Spring Cloud包含了多个子项目(针对分布式系统中涉及的多个不同开源产品),比如:Spring Cloud Config.Spring Cloud Netflix.Spring Cloud0 CloudFoundry.