服务设计

1 聚合器微服务设计模式 这是一种最常用也最简单的设计模式，如下图所示： 聚合器调用多个服务实现应用程序所需的功能。它可以是一个简单的Web页面，将检索到的数据进行处理展示。它也可以是一个更高层次的组合微服务，对检索到的数据增加业务逻辑后进一步发布成一个新的微服务，这符合DRY原则。另外，每个服务都有自己的缓存和数据库。如果聚合器是一个组合服务，那么它也有自己的缓存和数据库。聚合器可以沿X轴和Z轴独立扩展。 2 链式微服务设计模式 这种模式在接收到请求后会产生一个经过合并的响应，如下图所示： 在这种情况下，服务A接收到请求后会与服务B进行通信，类似地，服务B会同服务C进行通信。所有服务都使用同步消息传递。在整个链式调用完成之前，客户端会一直阻塞。因此，服务调用链不宜过长，以免客户端长时间等待。 3 分支微服务设计模式 这种模式是聚合器模式的扩展，允许同时调用两个微服务链，如下图所示： 4 代理微服务设计模式 这是聚合器模式的一个变种，如下图所示： 在这种情况下，客户端并不聚合数据，但会根据业务需求的差别调用不同的微服务。代理可以仅仅委派请求，也可以进行数据转换工作。 5 异步消息传递微服务设计模式 虽然REST设计模式非常流行，但它是同步的，会造成阻塞。因此部分基于微服务的架构可能会选择使用消息队列代替REST请求/响应，如下图所示： 6 数据共享微服务设计模式

前言 今天和大家聊一下在采用Spring Cloud进行微服务架构设计时，微服务之间调用时异常处理机制应该如何设计的问题。我们知道在进行微服务架构设计时，一个微服务一般来说不可避免地会同时面向内部和外部提供相应的功能服务接口。面向外部提供的服务接口，会通过服务网关（如使用Zuul提供的apiGateway）面向公网提供服务，如给App客户端提供的用户登陆、注册等服务接口。 而面向内部的服务接口，则是在进行微服务拆分后由于各个微服务系统的边界划定问题所导致的功能逻辑分散，而需要微服务之间彼此提供内部调用接口，从而实现一个完整的功能逻辑，它是之前单体应用中本地代码接口调用的服务化升级拆分。例如，需要在团购系统中，从下单到完成一次支付，需要交易系统在调用订单系统完成下单后再调用支付系统，从而完成一次团购下单流程，这个时候由于交易系统、订单系统及支付系统是三个不同的微服务，所以为了完成这次用户订单，需要App调用交易系统提供的外部下单接口后，由交易系统以内部服务调用的方式再调用订单系统和支付系统，以完成整个交易流程。如下图所示： 这里需要说明的是，在基于SpringCloud的微服务架构中，所有服务都是通过如consul或eureka这样的服务中间件来实现的服务注册与发现后来进行服务调用的，只是面向外部的服务接口会通过网关服务进行暴露，面向内部的服务接口则在服务网关进行屏蔽

微服务 1 微服务的介绍 1.1 微服务的定义 微，狭义来讲就是体积小、著名的"2 pizza 团队"很好的诠释了这一解释（2 pizza 团队最早是亚马逊 CEO Bezos提出来的，意思是说单个服务的设计，所有参与人从设计、开发、测试、运维所有人加起来 只需要2个披萨就够了 ）。 而所谓服务，一定要区别于系统，服务一个或者一组相对较小且独立的功能单元，是用户可以感知最小功能集。 1.2微服务的由来 微服务最早由Martin Fowler与James Lewis于2014年共同提出，微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理 1.3微服务的特点 微服务架构和其他架构的对比 特点： 1）集中式架构：单体无分散 2）分布式架构：分散压力 3）微服务架构：分散能力 微服务架构优势 1）每个微服务组件都是简单灵活的，能够独立部署。不再像单体应用时代，应用需要一个庞大的应用服务器来支撑。 2）可以由一个小团队负责更专注专业，相应的也就更高效可靠。 3）微服务之间是松耦合的，微服务内部是高内聚的，每个微服务很容易按需扩。 2 微服务的四种原则 2.1

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> RPC和RPC框架 1.RPC(Remote Procedure Call) 即远程过程调用, 主要解决远程通信间的问题，不需要了解底层网络的通信机制。 2.RPC框架 RPC框架负责屏蔽底层的传输方式（TCP或者UDP）、序列化方式、以及通信细节。 实际使用中，并不需要关心底层通信细节和调用过程，让业务端专注于业务代码的实现。 国内大家熟知的PRC框架，阿里的HSF和Dubbo(开源) Dubbo的发展由来 1. 业务规模小 比如早期一个应用Java War包，将所有功能都打包，部署在一个单机服务器，调用接口也比较方便，不涉及到任何分布式场景。 2.业务规模变大 随着业务的快速发展，业务越来越多、子系统也越来越多时。比如：淘宝的交易系统、商品系统、用户系统、评价系统…上百个系统的出现。 系统变得越来越复杂，业务代码依然耦合在一起。比如最早期的淘宝denali工程，包含所有业务系统的代码，就仅打包部署都需要很长的时间。 并且，随着每个业务线的快速发展，业务代码耦合在一起，上线后出现问题急需要回滚代码，拉分支、大量的代码merge工作，这个过程极其痛苦。 这个时候，你会发现技术已经成了业务的瓶颈，急需把业务单独抽离出来，各自单独部署。 3.Dubbo和HSF的出现 应用系统一旦涉及到拆分部署，问题就来了

在采用Spring Cloud进行微服务架构设计时，微服务之间调用时异常处理机制应该如何设计的问题。我们知道在进行微服务架构设计时，一个微服务一般来说不可避免地会同时面向内部和外部提供相应的功能服务接口。面向外部提供的服务接口，会通过服务网关（如使用Zuul提供的apiGateway）面向公网提供服务，如给App客户端提供的用户登陆、注册等服务接口。 而面向内部的服务接口，则是在进行微服务拆分后由于各个微服务系统的边界划定问题所导致的功能逻辑分散，而需要微服务之间彼此提供内部调用接口，从而实现一个完整的功能逻辑，它是之前单体应用中本地代码接口调用的服务化升级拆分。例如，需要在团购系统中，从下单到完成一次支付，需要交易系统在调用订单系统完成下单后再调用支付系统，从而完成一次团购下单流程，这个时候由于交易系统、订单系统及支付系统是三个不同的微服务，所以为了完成这次用户订单，需要App调用交易系统提供的外部下单接口后，由交易系统以内部服务调用的方式再调用订单系统和支付系统，以完成整个交易流程。如下图所示： 这里需要说明的是，在基于SpringCloud的微服务架构中，所有服务都是通过如consul或eureka这样的服务中间件来实现的服务注册与发现后来进行服务调用的，只是面向外部的服务接口会通过网关服务进行暴露，面向内部的服务接口则在服务网关进行屏蔽，避免直接暴露给公网

文章目录 作业内容 REST REST API设计 架构概述 部分API设计 用户登录 新建博客 修改博客 删除博客 查看博客 查看评论 发表评论 作业内容 模仿github API，用markdown编写设计一个博客网站的部分REST API。 REST REST（Representational State Transfer ， 表现层状态装换）是Roy Thomas Fielding博士于2000年在它的博士论文中提出的一种万维网软件 架构风格 （而不是标准），目的是便于不同软件/程序在网络中互相传递信息（详见 维基百科 ）。 REST API设计 假设博客根地址为 https://blog.com 。 架构概述 所有API访问使用HTTP协议，并通过 https://api.blog.com 进行访问。 所有数据以JSON形式发送接收，所有时间戳以ISO 8601格式（YYYY-MM-DDTHH:MM:SSZ）返回。 请求成功时响应状态返回2xx，失败时返回4xx或者5xx。 HTTP常用动词：PUT,DELETE,GET,POST,PATCH。 部分API设计 使用curl发送请求 错误信息 401 ：验证无效的凭据将返回401 HTTP/1.1 401 Unauthorized { "message": "Bad credentials", "documentation

1.1 什么是微服务 1.1.1 很小，专注于做好一件事 单一职责，一个团队维护 1.1.2 自治性 独立部署，修改一个服务不影响其它服务 1.2 主要好处 1.2.1 技术异构性 1.2.2 弹性 舱壁，不会导致级联故障 1.2.3 伸缩 只扩展存在性能的部分 1.2.4 简化部署 只会引起部署的服务，其它服务不受影响 1.2.5 与组织结构匹配 1.2.6 可组合性 易于重用已有功能 1.2.7 对可替代性的优化 1.3 面向服务的架构 SOA,微服务是SOA的特定实现 1.4 其它分解技术 1.4.1 共享库 1.4.2 模块化 OSGI，复杂度高 来源： https://www.cnblogs.com/lzf715/p/11923092.html

你如何考虑服务化 # 集中式与分布式 要谈微服务，那么必须建立在分布式的基础上，对于一个集中式系统也无需谈微服务。 # 集中式 集中式系统用一句话概括就是：一个主机带多个终端。终端没有数据处理能力，仅负责数据的录入和输出。而运算、存储等全部在主机上进行。 集中式系统的最大的特点就是部署结构非常简单，底层一般采用从IBM、HP等厂商购买到的昂贵的大型主机。因此无需考虑如何对服务进行多节点的部署，也就不用考虑各节点之间的分布式协作问题。但是，由于采用单机部署。很可能带来系统大而复杂、难于维护、发生单点故障（单个点发生故障的时候会波及到整个系统或者网络，从而导致整个系统或者网络的瘫痪）、扩展性差等问题。 # 分布式 分布式就是一群独立计算机集合共同对外提供服务，但是对于系统的用户来说，就像是一台计算机在提供服务一样。分布式意味着可以采用更多的普通计算机（相对于昂贵的大型机）组成分布式集群对外提供服务。计算机越多，CPU、内存、存储资源等也就越多，能够处理的并发访问量也就越大。 拿电商网站来说，我们一般把一个电商网站横向拆分成商品模块、订单模块、购物车模块、消息模块、支付模块等。然后我们把不同的模块部署到不同的机器上，各个模块之间通过远程服务调用( RPC )等方式进行通信。以一个分布式的系统对外提供服务。 # 服务化 提到分布式，一个不得不提的词就是服务化

1、业务需求的描述 假设面试官现在给出来对于这个电商平台的积分兑换系统的相关需求如下： 用户在电商平台里平时通过购买商品、晒单评论可以有不断的积累积分积累到足够的积分后，就可以在电商平台的积分兑换页面中，选择使用自己的积分来兑换一些礼品。 需求其实就这么简单，那么面试官说了，针对这个业务场景给出你对这个机制实现的思考过程以及这里要注意的一些地方。 2 、对业务流程的思考 如何思考？首先，用户不停的购买商品以及晒单评论，会不断的获取积分，那么是不是需要一张积分表，专门用来存储每个用户的积分呢？没错，这个表是一定需要的，可以现场给出下述的表结构。 积分表 ： id （自增 id主键） user_id （用户 id） credit （积分） 继续来看，假设在积分兑换页面，用户选择用自己的 20000积分兑换一瓶洗发水， 后台的逻辑应该如何设计呢？ 这个也是必须得现场给出一个思考过程的，这个其实看起来简单，但是很多年纪较轻，经验不足的朋友，可能没法快速思考出来。 首先你要用 20000积分去进行兑换，那么一定是必须要在积分表里扣减掉这20000积分的吧？所以在流程设计中，首先就得有一个20000积分扣减的过程。 其次，你用这 20000积分兑换了什么东西呢？ 所以你是不是还需要一张单独的表，叫做积分兑换记录表，记录下来你这个用户本次用多少积分兑换了一件什么商品？

一、微服务架构演进过程 近年来我们大家都体会到了互联网、移动互联带来的好处，作为IT从业者，在生活中时刻感受互联网好处的同时，在工作中可能感受的却是来自自互联网的一些压力，那就是我们传统企业的IT建设也是迫切需要转型，需要面向外部客户，我们也需要应对外部环境的快速变化、需要快速创新，那么我们的IT架构也需要向互联网企业学习作出相应的改进，来支撑企业的数字化转型。 我们再看一下应用架构的演进过程，回忆一下微服务架构是如何一步一步进化产生的，最早是应用是单块架构，后来为了具备一定的扩展和可靠性，就有了垂直架构，也就是加了个负载均衡，接下来是前几年比较火的SOA，主要讲了应用系统之间如何集成和互通，而到现在的微服务架构则是进一步在探讨一个应用系统该如何设计才能够更好的开发、管理更加灵活高效。 微服务架构的基本思想就是“围绕业务领域组件来创建应用，让应用可以独立的开发、管理和加速”。 二、微服务架构的好处 我们总结了四个方面的优点，分别如下： 是每个微服务组件都是简单灵活的，能够独立部署。不再像以前一样，应用需要一个庞大的应用服务器来支撑。 可以由一个小团队负责更专注专业，相应的也就更高效可靠。 微服务之间是松耦合的，微服务内部是高内聚的，每个微服务很容易按需扩展。 微服务架构与语言工具无关，自由选择合适的语言和工具，高效的完成业务目标即可。 看到这里，大家会觉得微服务架构挺不错