服务设计

--------------------------------------------------------------------------------- 单体架构到位服务 软件生命周期与架构演化 微服务立方体 最好的架构是演化过来 微服务拆分示例——典型电商系统的架构演化 微服务横向扩展划分——共享核心功能模式 微服务数据分区 --------------------------------------------------------------------------------------- 如何设计一个为服务系统 微服务系统的优缺点 优点 缺点 更为敏捷 整个系统更加复杂 更小，更专注的团队 开发和测试面临更多挑战 更小的codebase 分布式带来管控难题 自由选择不同的技术栈 网络瓶颈和延迟 问题隔离 数据一致性 扩展性/扩容容易 管理文化挑战 数据隔离 多服务版本对齐控制 技术能力要求高 微服务设计示例：Boat House无人机送餐系统 S1- 领域模型Domain Model设计 S3 单一领域结构分析(Shipping Domain) s4—— 单一领域流程f分析(Shipping Domain) S5—— 应用服务边界和条用关系设计 S7 应用服务部署设计 S8 服务见通讯机制设计 S9.CI/CD 流水线设计 ------------------

如果大家有印象的话，尤其是夏天，如果家里用电负载过大，比如开了很多家用电器，就会”自动跳闸”，此时电路就会断开。在以前更古老的一种方式是” 保险丝 ”，当负载过大，或者电路发生故障或异常时，电流会不断升高，为防止升高的电流有可能损坏电路中的某些重要器件或贵重器件，烧毁电路甚至造成火灾。保险丝会在电流异常升高到一定的高度和热度的时候，自身熔断切断电流，从而起到保护电路安全运行的作用。 同样，在大型的软件系统中，如果调用的远程服务或者资源由于某种原因无法使用时，如果没有这种过载保护，就会导致请求的资源阻塞在服务器上等待从而耗尽系统或者服务器资源。很多时候刚开始可能只是系统出现了局部的、小规模的故障，然而由于种种原因，故障影响的范围越来越大，最终导致了全局性的后果。软件系统中的这种过载保护就是本文将要谈到的熔断器模式(Circuit Breaker) 一 问题的产生 在大型的分布式系统中，通常需要调用或操作远程的服务或者资源，这些远程的服务或者资源由于调用者不可以控的原因比如网络连接缓慢，资源被占用或者暂时不可用等原因，导致对这些远程资源的调用失败。这些错误通常在稍后的一段时间内可以恢复正常。 但是，在某些情况下，由于一些无法预知的原因导致结果很难预料，远程的方法或者资源可能需要很长的一段时间才能修复。这种错误严重到系统的部分失去响应甚至导致整个服务的完全不可用。在这种情况下

转自：http://blog.csdn.net/smstong/article/details/5312136 我感觉维基百科说的REST解释的就听明白的，摘录下来： 含状态传输 （英文： Representational State Transfer ，简称 REST ）是 Roy Fielding 博士在2000年他的博士论文中提出来的一种软件架构风格。 目前在三种主流的Web服务实现方案中，因为REST模式与复杂的SOAP和XML-RPC相比更加简洁，越来越多的web服务开始采用REST风格设计和实现。例如， Amazon.com 提供接近REST风格的Web服务进行图书查找；雅虎提供的Web服务也是REST风格的。 要点及标准 需要注意的是，REST是设计风格而 不是 标准。REST通常基于使用 HTTP ， URI ，和XML以及HTML这些现有的广泛流行的协议和标准。 资源是由URI来指定。 对资源的操作包括获取、创建、修改和删除资源，这些操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法。 通过操作资源的表现形式来操作资源。 资源的表现形式则是XML或者HTML，取决于读者是机器还是人，是消费web服务的客户软件还是web浏览器。当然也可以是任何其他的格式 关于状态 应该注意区别应用的状态和连接协议的状态。HTTP连接是无状态的

REST是一种架构风格，其核心是面向资源，REST专门针对网络应用设计和开发方式，以降低开发的复杂性，提高系统的可伸缩性。REST提出设计概念和准则为： 1.网络上的 所有事物都可以被抽象为资源(resource) 2.每一个资源都有唯一的资源标识(resource identifier)，对资源的操作不会改变这些标识 3.所有的操作都是 无状态 的 REST简化开发，其架构遵循CRUD原则，该原则告诉我们对于资源(包括网络资源)只需要四种行为：创建，获取，更新和删除就可以完成相关的操作和处理。您可以通过统一资源标识符（Universal Resource Identifier，URI）来识别和定位资源，并且针对这些资源而执行的操作是通过 HTTP 规范定义的。 其核心操作只有GET,PUT,POST,DELETE。 由于REST强制所有的操作都必须是stateless的，这就没有上下文的约束，如果做分布式，集群都不需要考虑上下文和会话保持的问题。极大的提高系统的可伸缩性。 对于SOAP Webservice和Restful Webservice的选择问题，首先需要理解就是SOAP偏向于面向活动，有严格的规范和标准，包括安全，事务等各个方面的内容，同时SOAP强调操作方法和操作对象的分离，有WSDL文件规范和XSD文件分别对其定义。而REST强调面向资源

CSDN看到一篇介绍架构设计的博客，内容提纲挈领，内容丰富。依据原文整理，加上自己的理解和总结。 推荐给大家。点击原文可以查看出处。 原文链接： https://blog.csdn.net/hguisu/article/details/78258430 什么是架构和架构本质 在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。此君说的架构和彼君理解的架构未必是一回事。因此我们在讨论架构之前，我们先讨论架构的概念定义，概念是人认识这个世界的基础，并用来沟通的手段，如果对架构概念理解不一样，那沟通起来自然不顺畅。 Linux有架构，MySQL有架构，JVM也有架构，使用Java开发、MySQL存储、跑在Linux上的业务系统也有架构，应该关注哪一个？ 想要清楚以上问题需要梳理几个有关系又相似的概念：系统与子系统、模块与组建、框架与架构: 区分系统、模块、组件、框架和架构 S君： 区分系统、模块、组件、框架和架构 系统(system)和子系统：有 关联 的个体，根据某种 规则 运行，共同完成独特的 功能 。子系统：系统的组成部分。 模块(module)和组件(component)：模块和组件都是系统的组成部分，只是从不同角度拆分系统而已。 从逻辑角度拆分得到的是模块，从物理角度拆分得到的是组件。 模块是为了实现职责分离， 组件是为了实现复用。 框架

3 月，跳不动了？>>> CSDN看到一篇介绍架构设计的博客，内容提纲挈领，内容丰富。依据原文整理，加上自己的理解和总结。 推荐给大家。点击原文可以查看出处。 原文链接： https://blog.csdn.net/hguisu/article/details/78258430 什么是架构和架构本质 在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。此君说的架构和彼君理解的架构未必是一回事。因此我们在讨论架构之前，我们先讨论架构的概念定义，概念是人认识这个世界的基础，并用来沟通的手段，如果对架构概念理解不一样，那沟通起来自然不顺畅。 Linux有架构，MySQL有架构，JVM也有架构，使用Java开发、MySQL存储、跑在Linux上的业务系统也有架构，应该关注哪一个？ 想要清楚以上问题需要梳理几个有关系又相似的概念：系统与子系统、模块与组建、框架与架构: 区分系统、模块、组件、框架和架构 S君： 区分系统、模块、组件、框架和架构 系统(system)和子系统：有 关联 的个体，根据某种 规则 运行，共同完成独特的 功能 。子系统：系统的组成部分。 模块(module)和组件(component)：模块和组件都是系统的组成部分，只是从不同角度拆分系统而已。 从逻辑角度拆分得到的是模块，从物理角度拆分得到的是组件。 模块是为了实现职责分离， 组件是为了实现复用。 框架

ITIL@2011 ITIL®2011流程总览 IT服务的生命周期 ITIL®V3 对IT服务生命周期的指导 服务战略 服务战略部分对如何设计、发展与实施服务管理提供了指导，并指导如何将服务管理作为战略资产而不仅仅作为一项组织能力进行管理。 服务设计 服务设计部分提供服务于服务管理流程的设计与开发指导。 服务转换 服务转换部分提供如何将服务设计所编码的服务战略需求在服务运营阶段有效地实现，控制失败与中断的风险。 服务运营 服务运营部分提供有效以及有效率地交付于支持服务的指导，从而保障客户与服务提供方的价值。 服务持续改进 服务持续改进部分提供通过更好的设计、引入和运营为客户创造和创造维护价值的指导。 行业标准：ISO/IEC 20000 ITIL®提供有效的知识体系以达到标准要求 ISO/IEC 2000是可以获得和维护的标准 来源： 51CTO 作者： xmcl123 链接： https://blog.51cto.com/5373107/2480737

3 月，跳不动了？>>> 作者：成富，资深架构师，拥有多年一线开发经验，曾就职于IBM，后移居海外创业，现任公司首席软件工程师，负责基于微服务架构的云原生产品研发。资深技术作家，著有多部中英文技术书籍：《深入理解 Java7 》《Exploring Java9》等。 *本文经作者授权整理发布，内容选自 《云原生微服务架构实战精讲》 云原生应用的概念 顾名思义，云原生应用的概念由云和原生两个部分组成，云在这里指的是云平台，也就是平台即服务（Platform as a Service，PaaS）；原生应用指的是专门针对云平台而设计和实现的，充分利用了云平台的特性。应用的微服务可以专注于实现业务逻辑，而把微服务架构的复杂度交给云平台来解决。 原生这个词在软件开发中有它独特的含义。原生通常意味着高效和难以移植，也意味着针对特定的平台而设计，可以充分利用平台的特性，因此运行起来非常高效；同样意味着与特定平台的深度绑定，很难移植到其他平台。云原生应用同样具有这两个特征，对于云原生应用来说，难移植并不是一个问题，毕竟迁移到云平台之后，不会再想迁移回去。 云原生应用的特征 与其他应用相比，总结起来，云原生应用有如下 15 个特征。 1、单一代码库 云原生应用必须有单一的代码库，并在版本管理系统中进行追踪。单一代码库可以是一个版本库，也可以是共享同一根目录的多个版本库，其重要性在于每一个代码提交

架构师在软件项目中的作用是提供待解决问题的工作模型。架构师的工作是提供脚手架，开发人员将根据这些脚手架构建他们的代码，使应用程序所有部件都组合在一起。 在构建微服务架构时，项目的架构师主要关注以下3个关键任务： （1）分解业务问题； （2）建立服务粒度； （3）定义服务接口。 2.1.1　分解业务问题 面对复杂性，大多数人试图将他们正在处理的问题分解成可管理的块。因为这样他们就不必努力把问题的所有细节都考虑进来。他们将问题抽象地分解成几个关键部分，然后寻找这些部分之间存在的关系。 在微服务架构中，架构师将业务问题分解成代表离散活动领域的块。这些块封装了与业务域特定部分相关联的业务规则和数据逻辑。 虽然我们希望微服务封装执行单个事务的所有业务规则，但这并不总是行得通。我们经常会遇到需要跨业务领域不同部分的一组微服务来完成整个事务的情况。架构师通过查看数据域中那些不适合放到一起的地方来划分一组微服务的服务边界。 例如，架构师可能会看到代码执行的业务流程，并意识到它们同时需要客户和产品信息。存在两个离散的数据域时，通常就意味着需要使用多个微服务。业务事务的两个不同部分如何交互通常成为微服务的服务接口。 分离业务领域是一门艺术，而不是非黑即白的科学。读者可以使用以下指导方针将业务问题识别和分解为备选的微服务。 （1） 描述业务问题，并聆听用来描述问题的名词 。在描述问题时

待做的： 学习框架：nameko、double、spring cloud、书 微服务的定义： 一些协同工作的小而自治的服务 微服务的核心思想： 1.自治： 1）每个微服务（APP）可以独立部署到PAAS（platform as a service）上 2）作为服务方，需要避免方暴露过多给消费而产生耦合，从而降低服务的自治性。要封装好，服务方内部实现修改，不该影响到消费方。 2.细粒度： 1）解耦：避免系统臃肿、难以维护 2）内聚性：相同的东西放在一起 3.隔离性： 1）各服务直接均通过网络调用进行通信（而不是代码调用），避免了紧耦合 2）各服务之间通过API调用，API解耦性必须要好，以保证技术的选择不被限制 3）一个黄金法则：你是否能够修改一个服务并对其进行部署，而不影响其他任何服务？（独立部署） 微服务的优点： 1.细粒度-》扩展性好-》可以快速响应变化、快速交付-》可以尝试更多的新技术 2.增加了团队的自治力 3.技术异构性。可以根据不同的业务场景，选择不同的技术，来构架服务。比如某个APP对性能有特别高的要求。或者某些APP对底层数据库有特别的要求（图数据库、文档数据库、关系型数据库）。这点需要APP足够小，可以快速重写，从而降低风险。还有就是框架要支持多语言开发业务模块。 4.弹性（稳定性、可用性）：第11章，详解 5.扩展：可以很容易把独立的服务，分割出去独立部署