服务设计

这篇文章讲的太好了，生怕以后被删掉。转到我博文列表里把-。- 正文： 开发者在刚开始尝试实现自己的微服务架构时往往会产生一系列问题 ： 微服务到底应该怎么划分？ 一个典型的微服务到底应该有多微？ 如果做了微服务设计，最后真的会有好处吗？ 回答上面的问题需要首先了解微服务设计的逻辑，科学的架构设计应该通过一些输入并逐步推导出结果，架构师要避免凭空设计和“拍脑门”的做法。 解耦的单体应用和微服务系统在逻辑上是一样的。对于服务拆分的逻辑来说，先设计高内聚低耦合的领域模型，再实现相应的分布式系统是一种比较合适的方式。 服务的划分有一些基本的方法和原则，通过这些方法能让微服务划分更有操作性。最终在微服务落地实施时也能按图索骥，无论是对遗留系统改造还是全新系统的架构都能游刃有余。 微服务拆分的几个阶段 在开始划分微服务之前，架构师需要在大脑中有一个重要的认识：微服务只是手段，不是目的。 微服务架构是为了让系统变得更容易拓展、更富有弹性。在把单体应用变成靠谱的微服务架构之前，单体系统的各个模块应该是合理、清晰地。 也就是说，从逻辑上单体系统和微服务没有区别，某种理想情况下微服务只是把单体系统的各个模块分开部署了而已（最近流行的monorepo把多个服务的代码仓库以模块的形式组织到了一起，证明了这一点）。 大量的实践教训告诉我们，混沌的微服务架构，比解耦良好的单体应用会带来更多麻烦。

提前先祝大家春节快乐！好了，先简单聊聊。 我从事的是大数据开发相关的工作，主要负责的是大数据计算这块的内容。最近Hive集群跑任务总是会出现Thrift连接HS2相关问题，研究了解了下内部原理，突然来了兴趣，就想着自己也实现一个RPC框架，这样可以让自己在设计与实现RPC框架过程中，也能从中了解和解决一些问题，进而让自己能够更好的发展（哈哈，会不会说我有些剑走偏锋？不去解决问题，居然研究RPC。别急，这类问题已经解决了，后续我也会发文章详述的）。 原理图上我已经标出来流程序号，我们来走一遍： ① Client以本地调用的方式调用服务 ② Client Stub接收到调用后，把服务调用相关信息组装成需要网络传输的消息体，并找到服务地址（host:port），对消息进行 编码 后交给Connector进行发送 ③ Connector通过网络通道发送消息给Acceptor ④ Acceptor接收到消息后交给Server Stub ⑤ Server Stub对消息进行 解码 ，并根据解码的结果通过 反射 调用本地服务 ⑥ Server执行本地服务并返回结果给Server Stub ⑦ Server Stub对返回结果组装打包并 编码 后交给Acceptor进行发送 ⑧ Acceptor通过网络通道发送消息给Connector ⑨ Connector接收到消息后交给Client Stub

写这篇文章是目的不是介绍Web-Service, 而是从Restful Web Service说起来剖析一下 什么才 是真正的Restful Style的架构与协议，从而更好的理解web服务的设计理念与架 构本质。 一：Web Service基础知识 一个最简单web服务就一个web页面等待请求与处理。更容易理解的方式是Web Service 可以把一个应用变成一个基本WEB方式的请求与处理的应用。常见的两种 Web Service处理 方式为： a. 基于WSDL/SOAP的方式 b. Rest方式 方式a是比较正统的，客户端调用必须先取得WSDL文件，然后生成调用的API才可 以使用。 它不是我要说的重点，基本调用流程如下： 方式b是Rest方式，Rest的Web Service的设计原则是基于CRUD，其支持四种操作分 别为： GET – 获取信息/请求信息内容，绝大多数浏览器获取信息时使用该方式。 POST – 增加信息内容，显示以前的信息内容，可以看作是insert操作 PUT – 更新信息内容，相当与update DELETE – 删除信息内容可以看作是delete Rest方式更加简单便捷，如果从设计原则上看HTTP协议本身已经是最Restful风格的 协议了 HTTP协议很好的支持了CRUD的操作。正是因为如此，WEB2.0以来, 基于 Restful的Web

0. 题型 0.1 内容要求 摘要字数在 400 字以内，可以分条叙述，但不允许有图、表和流程图。 正文字数为 2000 字至 3000 字，文中可以分条叙述，但不要全部用分条叙述的方式。 0.2 题目 第一题 介绍主题相关的项目 可以包含以下内容 开发背景 总体需求 采用的技术体制 （使用该技术/方法的、该项目的）动机与期望 介绍担任的主要工作 第二题 理论描述，因主题而异 第三题 如何应用到项目中的，比如用到里理论中提到的哪些概念，又是如何实现的，实施效果又如何。 遇到了哪些问题，又是怎么解决的，实施效果又怎么样？ 0.3 注意 细心审题，问的是什么 备考阶段要专心于自己最熟悉、最复杂、最高级的系统或项目，因此这个系统或项目中自己不熟悉的部分就不要准备了，免得到时候瞎扯。所以后面这种都加上了 删除线 。 1. 软件架构（体系结构）设计 2018，论软件体系结构的演化 软件体系结构的演化是在构件开发过程中或软件开发完毕投入运行后，由于用户需求发生变化，就必须相应地修改原有软件体系结构，以满足新的变化了的软件需求的过程。体系结构的演化是一个复杂的、难以管理的问题。 概要叙述你参与管理和开发的软件项目以及你在其中所承担的主要工作。 软件体系结构的演化是使用系统演化步骤去修改系统，以满足新的需求。简要论述系统演化的6个步骤。

其它服务为了从某个服务中获取信息，采用直接读取数据库的方式。如果需要修改记录，也是直接修改数据库表中的记录。这种集成方式很容易，所以也很普遍。 这种集成方式是很容易，但却也存在着很多问题： 首先，数据库变为一个大的共享 API。如果，某个服务想要改变业务逻辑，就必须直接改库。为了不影响其它服务，修改表结构时就必须非常小心，并且需要做大量的回归测试来保证质量。 服务使用者所选用的技术栈必须与共享数据库相容，即被限制了。假设，现在用的是关系数据库；未来，随着业务的发展，可能改用非关系数据库。只有隐藏了实现细节，才能让其它服务拥有自主权，并可自由修改内部实现，实现松耦合。 使用共享数据库集成模式，很难实现高内聚与低耦合，所以应该尽可能避免使用该模式。 来源： https://blog.csdn.net/deniro_li/article/details/101147451

假设在一个应用中，客户注册了一个新账号，而这个动作会触发以下逻辑： 在客户的积分账户中创建一条积分记录； 通过邮政系统派送一个欢迎礼包； 向客户发送欢迎电子邮件； 创建新账号的流程图为： 考虑具体实现时 , 有两种架构可以选择 。 1 编排 (orchestration) 编排架构，会有某个中心大脑来领导并驱动整个流程 , 这个大脑就像交响乐队中的指挥。 编排架构的缺点是 , 客户服务作为中心控制点承担了太多职责 , 它会成为网状结构的中心枢纽及很多逻辑的起点 。 这种架构可能会导致出现 “老大哥 ” 服务 , 而与其打交道的其它服务会沦为仅是基于 CRUD 的 “贫血” 服务。 2 协同 (choreography) 协同架构，会预先说明清楚系统中各个部分各自的职责 , 而把具体怎么实现留给各个部分它们自己 。 在刚才的示例中，我们可以使用异步的方式从客户服务中触发一个名为“ 客户创建 ”的事件 。 积分服务、包裹服务以及邮件服务订阅这个事件 。 这种架构的好处是能够显著地消除耦合 。 这种架构的缺点是 , 不能直观地看出整体业务流程 。因此，我们必须监控整套流程 , 以确保其能正确地流转 。这需要构建一套与上图业务流程相匹配的监控系统。 总的来说，协同架构不仅可以降低系统的耦合度 , 还可以让我们以更加灵活的方式修改现有系统。 应该根据具体的实际技术，来选择最适宜的架构。 来源

在微服务架构中，需要调用很多服务才能完成一项功能。服务之间如何互相调用就变成微服务架构中的一个关键问题。服务调用有两种方式，一种是RPC方式，另一种是事件驱动（Event-driven）方式，也就是发消息方式。消息方式是松耦合方式，比紧耦合的RPC方式要优越，但RPC方式如果用在适合的场景也有它的一席之地. 耦合的种类： 我们总在谈耦合，那么耦合到底意味着什么呢？ 时间耦合：客户端和服务端必须同时上线才能工作。发消息时，接受消息队列必须运行，但后台处理程序暂时不工作也不影响。 容量耦合：客户端和服务端的处理容量必须匹配。发消息时，如果后台处理能力不足也不要紧，消息队列会起到缓冲的作用。 接口耦合：RPC调用有函数标签，而消息队列只是一个消息。例如买了商品之后要调用发货服务，如果是发消息，那么就只需发送一个商品被买消息。 发送方式耦合：RPC是点对点方式，需要知道对方是谁，它的好处是能够传回返回值。消息既可以点对点，也可以用广播的方式，这样减少了耦合，但也使返回值比较困难。 下面我们来逐一分析这些耦合的影响。 第一，时间耦合，对于多数应用来讲，你希望能马上得到回答，因此即使使用消息队列，后台也需要一直工作。第二，容量耦合，如果你对回复有时间要求，那么消息队列的缓冲功能作用不大，因为你希望及时响应。真正需要的是自动伸缩（Auto-scaling）

笔记 4、微服务下电商项目基础模块设计 简介：微服务下电商项目基础模块设计 分离几个模块，课程围绕这个基础项目进行学习 小而精的方式学习微服务 1、用户服务 1）用户信息接口 2）登录接口 2、商品服务 1）商品列表 2）商品详情 3、订单服务 1）我的订单 2）下单接口 开始 来源： https://www.cnblogs.com/wangjunwei/p/11440248.html

1、什么是架构和架构本质 在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。 此君说的架构和彼君理解的架构未必是一回事。 LInux有架构，MySQL有架构，JVM也有架构，使用Java开发、MySQL存储、跑在Linux上的业务系统也有架构，应该关注哪一个？想要清楚以上问题需要梳理几个有关系又相似的概念：系统与子系统、模块与组建、框架与架构: 一、系统与子系统 系统：泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能独立完成的工作能力的群体。 子系统：也是由一群关联的个体组成的系统，多半是在更大的系统中的一部分。 二、模块与组件 都是系统的组成部分，从不同角度拆分系统而已。模块是逻辑单元，组件是物理单元。 模块就是从逻辑上将系统分解， 即分而治之， 将复杂问题简单化。模块的粒度可大可小， 可以是系统，几个子系统、某个服务，函数， 类，方法、 功能块等等。 三、框架与架构 框架是组件的规范，例如：MVC、MVP、MVVM等，是提供基础功能的产品，例如：Ruby on Rails、Spring、Laravel、Django等。 框架是规范，架构是结构。 我在这重新定义架构：软件架构指软件系统的顶层结构。 架构是经过系统性地思考, 权衡利弊之后在现有资源约束下的最合理决策, 最终明确的系统骨架: 包括子系统, 模块, 组件. 以及他们之间协作关系,

文章讲的不错，更具体一些，对实践的指导意义更强 原文： https://www.infoq.cn/article/rest-introduction/ 不知你是否意识到，围绕着什么才是实现异构的应用到应用通信的“正确”方式，一场争论正进行的如火如荼：虽然当前主流的方式明显地集中在基于 SOAP、WSDL 和 WS-* 规范的 Web Services 领域，但也有少数人用细小但洪亮的声音主张说更好的方式是 REST，表述性状态转移（REpresentational State Transfer）的简称。在本文中，我不会涉及争论的话题，而是尝试对 REST 和 RESTful HTTP 应用集成做实用性的介绍。以我的经验，有些话题一旦触及就会引来众多的讨论，当涉及到这方面话题的时候，我会深入详细地阐述。 REST 关键原则 大部分对 REST 的介绍是以其正式的定义和背景作为开场的。但这儿且先按下不表，我先提出一个简单扼要的定义：REST 定义了应该如何正确地使用（这和大多数人的实际使用方式有很大不同）Web 标准，例如 HTTP 和 URI。如果你在设计应用程序时能坚持 REST 原则，那就预示着你将会得到一个使用了优质 Web 架构（这将让你受益）的系统。总之，五条关键原则列举如下： 为所有“事物”定义 ID 将所有事物链接在一起 使用标准方法 资源多重表述 无状态通信