分布式架构

简单阐述一下自己对分布式事物的理解，如有错误欢迎指正： 刚性事物：即ACID这里不做过多解释，有不明白的同学建议快速掌握。 柔性事物：简单来说为运行过程不一致但最终保持一致。 一、产生原因： 　　分布式(微服务)系统中之间的跨库访问(例：商城项目中的会员数据库，订单数据库，支付数据库等、、、)与同一项目多数据源不同，使用于分布式系统后类似SOA接口之间调用时产生。 二、解决原理： 1）、CAP原理(即：一致性，可用性，分区容错性) 一致性：当系统对一个数据进行写操作时成功后，在查询则必须是改动后的值，当写操作失败也就必须查不多新值，在单机项目中又叫原子性。 　　 可用性：服务可用性，就是说所有的读写请求在一定时间内要得到响应，不能一直等待下去。 　　 分区容错性：指在分布式、微服务系统中，当 部分服务宕机后，其他核心服务能够不受影响能够继续提供服务。 2）、BAS理论： 　 采用CAP演化而来，是对CAP中一致性和可用性权衡的结果，核心思想是：即使无法做到强一致性，但每个业务根据自身的特点，采用适当的方式来使系统达到最终一 　　致 性。主要有以下状态： 　　 基本可用：在分布式系统出现故障时，允许损失部分可用性，保证核心可用，例如：一个服务正常响应时间为：2秒之内，在访问量大时可采用可对部分用户进行降级处理 　　 软状态：允许系统存在中间状态，并且该状态不会允许系统整体可用性

原文: 最全的.NET Core跨平台微服务学习资源 一、Asp.net Core基础 微软中文官网：https://docs.microsoft.com/zh-cn/aspnet/core/getting-started/ 微软英文官网：https://docs.microsoft.com/en-us/aspnet/core/ .NET Core：http://www.dot.net GitHub：https://github.com/aspnet 用ASP.NET内核和Azure构建现代Web应用程序：https://docs.microsoft.com/en-us/dotnet/standard/modern-web-apps-azure-architecture/ 博客园翻译文档：https://www.cnblogs.com/dotNETCoreSG/p/aspnetcore-index.html MSDN：https://blogs.msdn.microsoft.com/ .NET Core开源峰会：https://github.com/dncto/dnc https://dotnet.github.io/ Artech：https://dotnet.github.io/博客 张飞洪博客：https://www.cnblogs.com/jackyfei/p

从本地事务到分布式事务到微服务下事务 一、传统本地事务 传统单服务器，单关系型数据库下事务比较简单，完全可用很简单的实现ACID，实际中我们实现一个业务时只需要：开启一个事务-操作数据库-提交/回滚这个事务，这样就完美的实现了一次事务操作，更简单点我们通常会通过spring集成事务直接指定在哪些服务什么样的方法执行什么样的事务即可，更甚至我们业务实现基本都忽略了事务，具体图如下： 二、传统分布式事务 在传统一服务，一个关系数据库架构基础上，随着访问量的增大，单机很明显已满足不了现状，于是我们顺其自然的就考虑到了服务集群部署，数据库分库分表，从而也就实现了这样一个样子，如图： 解释：服务水平扩展，数据库分库分表压力是将下来了，但同时也来了另一个问题，如果我一次请求中同时操作了多个DB这个时候我们的传统事务模式（一）就已经不行了，于是我们就在网上各种搜，终于找到了一个叫2PC（二阶段提交）的东西，具体操作如图： 大概意思： 在最外层有一个事务管理器（TM）来控制整个事务，一个请求过来， 第一阶段：事务管理器通知各个资源管理器（RM）准备提交事务，这时我们处理完业务各个RM准备完毕后给TM一个响应（业务正常/异常） 第二阶段：1、如果反馈TM业务正常那么TM会通知RM可提交事务，如果异常，通知回滚事务 大概就是这个意思，具体可百度 三、微服务下事务 分布式系统，随着业务的不断增加

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

一.软件架构的演进 1.单体结构 前端+中间件业务逻辑层+数据库层 2.分布式应用 中级架构，分布式应用 中间层分布式+数据库分布式 解决了高并发问题，降低了耦合度，责任清晰，扩展方便，部署方便，提高代码的复用性。 系统交互要使用远程通信，接口开发增大工作量 3.微服务架构 中间层分解，将系统拆分为很多的小应用（微服务） 4.Serverless架构 二.23种设计模式（日记中有） 三.今日份Java问题 1.JDK、JRE、JVM三者之间的关系，以及JDK、JRE包含的主要结构有哪些 2.为什么要配置path环境变量，如何配置 3.常见的几个命令行操作有哪些 来源： https://www.cnblogs.com/codekaterina/p/11891995.html

谈谈业务中使用分布式的场景 首先，需要了解系统为什么使用分布式。 随着互联网的发展，传统单工程项目的很多性能瓶颈越发凸显，性能瓶颈可以有几个方面： 1.应用服务层：随着用户量的增加，并发量增加，单项目难以承受如此大的并发请求导致的性能瓶颈。 2.底层数据库层：随着业务的发展，数据库压力越来越大，导致的性能瓶颈。 #场景1：应用系统集群的 Session 共享 应用系统集群最简单的就是服务器集群，比如：Tomcat 集群。应用系统集群的时候，比较凸显的问题是 Session 共享，Session 共享我们一是可以通过服务器插件来解决。另外一种也可以通过 Redis 等中间件实现。 #场景2：应用系统的服务化拆分 服务化拆分，是目前非常火热的一种方式。现在都在提微服务。通过对传统项目进行服务化拆分，达到服务独立解耦，单服务又可以横向扩容。服务化拆分遇到的经典问题就是分布式事务问题。目前，比较常用的分布式事务解决方案有几种：消息最终一致性、TCC 补偿型事务等。 #场景3：底层数据库的压力分摊 如果系统的性能压力出现在数据库，那我们就可以读写分离、分库分表等方案进行解决。 Session 分布式方案 #基于 nfs(net filesystem) 的 Session 共享 将共享服务器目录 mount 各服务器的本地 session 目录，session 读写受共享服务器 io 限制

关于Scrapy工作流程回顾 Scrapy单机架构 上图的架构其实就是一种单机架构，只在本机维护一个爬取队列，Scheduler进行调度，而要实现多态服务器共同爬取数据关键就是共享爬取队列。 分布式架构 将上图进行再次更改 这里重要的就是我的队列通过什么维护？ 关于爬取队列我们自然想到的是基于内存存储的Redis。它支持多种数据结构，如：列表、集合、有序集合等,存取的操作也非常简单。 Redis支持的这几种数据结构，在存储中都有各自优点： 列表(list)有lpush()、lpop()、rpush()、rpop()方法，可以实现先进先出的队列和先进后出的栈式爬虫队列。 集合(set)的元素是无序且不重复的，这样我们可以非常方便的实现随机且不重复的爬取队列。 有序集合有分数表示，而Scrapy的Request也有优先级的控制，我们可以用它来实现带优先级调度的队列。 如何去重？ 这里借助redis的集合，redis提供集合数据结构，在redis集合中存储每个request的指纹 在向request队列中加入Request前先验证这个Request的指纹是否已经加入集合中。如果已经存在则不添加到request队列中，如果不存在，则将request加入到队列并将指纹加入集合 如何防止中断？如果某个slave因为特殊原因宕机，如何解决？ 在Scrapy中

一、Asp.net Core基础 微软英文官网：https://docs.microsoft.com/en-us/aspnet/core/?view=aspnetcore-2.1 .NET Core：http://www.dot.net 微软中文官网：https://docs.microsoft.com/zh-cn/aspnet/core/getting-started/?view=aspnetcore-2.1&tabs=windows GitHub：https://github.com/aspnet 用ASP.NET内核和Azure构建现代Web应用程序：https://docs.microsoft.com/en-us/dotnet/standard/modern-web-apps-azure-architecture/ 博客园翻译文档：https://www.cnblogs.com/dotNETCoreSG/p/aspnetcore-index.html MSDN：https://blogs.msdn.microsoft.com/ .NET Core开源峰会：https://github.com/dncto/dnc https://dotnet.github.io/ Artech：https://dotnet.github.io/博客 张飞洪博客：https://www

课程介绍 微服务架构的技术体系、社区目前已经越来越成熟。在最初系统架构的搭建，或者当现有架构已到达瓶颈需要进行架构演进时，很多架构师、运维工程师会考虑是否需要搭建微服务架构体系。虽然很多文章都说微服务架构是复杂的、会带来很多分布式的问题，但只要我们了解这些问题，并找到解法，就会有种拨开云雾的感觉。 微服务架构也不是完美的，世上没有完美的架构，微服务架构也是随着业务、团队成长而不断演进的。最开始可能就几个、十几个微服务，每个服务是分库的，通过 API Gateway 并行进行服务数据合并、转发。随着业务扩大、不断地加入搜索引擎、缓存技术、分布式消息队列、数据存储层的数据复制、分区、分表等。 本课程会一一解开微服务架构下分布式场景的问题，以及通过对于一些分布式技术的原理、模型和算法的介绍，来帮助想要实施微服务架构的工程师们知其然并知其所以然。并且，本课程通过对分布式问题的体系化梳理，结合一些方案的对比选型，可以让工程师们一览微服务的知识图谱。 注：为了方便初学者理解微服务实践，以及掌握怎样在微服务中使用 DDD（Domain-Driven Design）思想，在本课程第 05 课中讲解了 Demo 示例，该示例是基于 Spring Boot、Spring Cloud Eureka 技术写的，Microservice 代码详见这里，Gateway 代码详见这里。 专家推荐

写在前面 https://www.cnblogs.com/gengzhe/p/ray_actor.html Orleans是基于Actor模型思想的.NET领域的框架，它提供了一种直接而简单的方法来构建分布式大规模计算应用程序，而无需学习和应用复杂的并发或其他扩展模式。我在2015年下半年开始应用Orleans，当时公司的交易系统采用的架构就是基于Orleans框架的，其展现出来的高性能、高并发以及惊人的稳定性深深地吸引了我，也让我认识到了传统三层无状态架构的缺陷。本文主要关注Orleans的思想基础，Actor模型及其应用。 Orleans思想基础：Actor模型 传统三层无状态架构的缺陷 在讨论Actor模型之前，我们可以先讨论一下传统三层架构在当前高并发环境中所面临的尴尬境遇。 三层架构包括表示层、业务逻辑层或者叫做中间层、数据访问层（也就是存储层），其架构图如下所示： 正如我们在实践中所知道的那样，中间层和数据访问层在伸缩性方面有着很大的限制，同时存储层常常会成为系统的瓶颈，这就意味着整套系统也会因为存储层的限制而变得低效。通常的做法是在中间层与存储层中间加一层缓存逻辑出来，以提升系统性能，但是很快就会遇到存储层与缓存层的数据一致性问题，这无疑为开发人员和运维人员增加了额外的工作量。 试想一下，如果我们中间层本身就携带着状态或者简单来说中间层与缓存层是合二为一的