推广 热搜: 风动潜水泵  DXBL1536/127井下UPS电源  空气炮厂家  分销商城  BQG450/0.2气动隔膜泵  厂家直销  期货  万利期权  破拱助流装置  Bc支付接口 

分布式一致性相关的理论CAPCA、CP、AP的相关算法的介绍以及适合用于哪些实践-电子邮件

   日期:2020-11-22     浏览:2    评论:0    
核心提示:  近年来随着互联网的快速发展尤其是移动互联网以及云计算的迅猛发展对于软件交付与迭代速度和效率的要求在不断提高。微服务架

  近年来随着互联网的快速发展尤其是移动互联网以及云计算的迅猛发展对于软件交付与迭代速度和效率的要求在不断提高。微服务架构凭借其简单清晰、灵活可扩展、独立部署等优势越来越成为了分布式架构中的主流。相关的书籍和课程也层出不穷但更多还是集中在基本理论介绍和一个简单的示例上。本系列课程内容融合了作者多年的实践经验将微服务架构下的一些经典的分布式问题和场景逐一展开结合最新的技术潮流理论结合实际深入剖析讲解并且给出了很多对于具体实践选型非常有益的建议。可以说该课程内容融合了作者从阿里巴巴到创业公司这一路走来所积累的精华是微服务及分布式领域难得的佳作。

  李静瑶2011 年毕业于中南大学校优秀毕业生、优秀学生干部毕业后入职阿里巴巴集团在职期间主要负责淘宝网营销产品线c;曾担任试用中心产品线c;在终点网络科技公司担任后端架构师以及参与 Android、iOS 等客户端研发。现就职于赤金信息科技有限公司担任 CTO 职位。从零搭建基于 Docker 容器技术的微服务分布式企业集群深度的 DDD 思想践行者。个人博客。

  微服务是一种服务间松耦合的、每个服务之间高度自治并且使用轻量级协议进行通信的可持续集成部署的分布式架构体系。这一句包含了微服务的特点微服务架构和其他架构有什么区别以下对比一些常见的架构。

  单体架构是最简单的软件架构常用于传统的应用软件开发以及传统 Web 应用。传统 Web 应用一般是将所有功能模块都打包jar、war在一个 Web 容器JBoss、Tomcat中部署、运行。随着业务复杂度增加、技术团队规模扩大在一个单体应用中维护代码会降低开发效率即使是处理一个小需求也需要将所有机器上的应用全部部署一遍增加了运维的复杂度。

  当某一天使用单体架构发现很难推进需求的开发、以及日积月累的技术债时很多企业会开始做单体服务的拆分拆分的方式一般有水平拆分和垂直拆分。垂直拆分是把一个应用拆成松耦合的多个独立的应用让应用可以独立部署有独立的团队进行维护水平拆分是把一些通用的会被很多上层服务调用的模块独立拆分出去形成一个共享的基础服务这样拆分可以对一些性能瓶颈的应用进行单独的优化和运维管理也在一定程度上防止了垂直拆分的重复造轮子。

  SOA 也叫面向服务的架构从单体服务到 SOA 的演进需要结合水平拆分及垂直拆分。SOA 强调用统一的协议进行服务间的通信服务间运行在彼此独立的硬件平台但是需通过统一的协议接口相互协作也即将应用系统服务化。举个易懂的例子单体服务如果相当于一个快餐店所有的服务员职责都是一样的又要负责收银结算又要负责做汉堡又要负责端盘子又要负责打扫服务员之间不需要有交流用户来了后服务员从前到后负责到底。SOA 相当于让服务员有职责分工收银员负责收银厨师负责做汉堡保洁阿姨负责打扫等所有服务员需要用同一种语言交流方便工作协调。

  微服务也是一种服务化不过其和 SOA 架构的服务化概念也是有区别的可以从以下几个关键字来理解

  松耦合每个微服务内部都可以使用 DDD领域驱动设计的思想进行设计领域模型服务间尽量减少同步的调用多使用消息的方式让服务间的领域事件来进行解耦。

  轻量级协议Dubbo 是 SOA 的开源的标准实现之一类似的还有像 gRPC、Thrift 等。微服务更倾向于使用 Restful 风格的 API轻量级的协议可以很好地支持跨语言开发的服务可能有的微服务用 Java 语言实现有的用 Go 语言有的用 C但所有的语言都可以支持 Http 协议通信所有的开发人员都能理解 Restful 风格 API 的含义。

  高度自治和持续集成从底层的角度来说SOA 更加倾向于基于虚拟机或者服务器的部署每个应用都部署在不同的机器上一般持续集成工具更多是由运维团队写一些 Shell 脚本以及提供基于共同协议比如 Dubbo 管理页面的开发部署页面。微服务可以很好得和容器技术结合容器技术比微服务出现得晚但是容器技术的出现让微服务的实施更加简便目前 Docker 已经成为很多微服务实践的基础容器。因为容器的特色所以一台机器上可以部署几十个、几百个不同的微服务。如果某个微服务流量压力比其他微服务大可以在不增加机器的情况下在一台机器上多分配一些该微服务的容器实例。同时因为 Docker 的容器编排社区日渐成熟类似 Mesos、Kubernetes 及 Docker 官方提供的 Swarm 都可以作为持续集成部署的技术选择。

  其实从架构的演进的角度来看整体的演进都是朝着越来越轻量级、越来越灵活的应用方向发展甚至到近两年日渐成熟起来的 Serverless无服务架构。从单体服务到分层的服务再到面向服务、再到微服务甚至无服务对于架构的挑战是越来越大。

  微服务架构属于分布式系统吗答案是肯定的。微服务和 SOA 都是典型的分布式架构只不过微服务的部署粒度更细服务扩展更灵活。

  怎样理解微服务中的分布式举个招聘时某同学来面试的例子。A 同学说目前所在公司在做从单应用到微服务架构迁移已经差不多完成了。提到微服务感觉就有线c;于是便问“是否可以简单描述下服务拆分后的部署结构、底层存储的拆分、迁移方案”。于是 A 同学说只是做了代码工程结构的拆分还是原来的部署方式数据库还是那个库所有的微服务都用一个库分布式事务处理方式是“避免”尽量都同步调用……于是我就跟这位同学友好地微笑说再见了。

  微服务的分布式不仅仅是容器应用层面的分布式其为了高度自治底层的存储体系也应该互相独立并且也不是所有的微服务都需要持久化的存储服务。一个“手机验证码”微服务可能底层存储只用一个 Redis一个“营销活动搭建页面”微服务可能底层存储只需要一个 MongoDB。

  微服务中的分布式场景除了服务本身需要有服务发现、负载均衡微服务依赖的底层存储也会有分布式的场景为了高可用性和性能需要处理数据库的复制、分区并且在存储的分库情况下微服务需要能保证分布式事务的一致性。

  微服务架构的技术体系、社区目前已经越来越成熟所以在初期选择使用或者企业技术体系转型微服务的时候需要了解微服务架构中的分布式的问题

  在所有服务都是更小单元的部署结构时一个请求需要调动更多的服务资源怎样获得更好的性能

  当业务规模增大需要有地理分布不同的微服务集群时其底层的数据存储集群是多数据中心还是单数据集群

  应该用哪些 RPC 技术用哪些分布式消息队列来完成服务通信和解耦

  那么多的分布式技术框架、算法、服务应该选哪个才适合企业的业务场景

  本课程从微服务不得不面对和解决的分布式问题出发包含分布式技术的一系列理论以及架构模型、算法的介绍同时结合技术选型和实践应用提供一系列解决方案的梳理。相信阅读完整个课程你会对微服务的分布式问题有个系统地理解。本课程会对微服务的分布式场景问题一一击破为你提供解决思路。

  引出分布式系统的可能问题节点故障、网络延迟结合错误检测的可行方案进行介绍

  分布式中的时间和顺序的问题以及标量时钟和向量时钟的实现。

  分布式数据存储的技术选型、关系型数据库以及一些流行的 NoSQL 技术介绍MongoDB、Redis、Neo4j 及 Cassandra 等

  分布式存储技术使用的数据结构了解底层数据存储原理HashTable、SSTable、LSMTree、BTree 等

  对于大规模存储集群需要进行数据库的复制、排除单点故障

  当单个领域模型维度的数据已经到一定规模时需要进行数据分区减轻单库压力。数据分区和分表又有哪些不同数据分区可以如何实现

  数据分区后请求的路由有哪些解决方案会展开介绍不同的方案又有什么差别。

  基于容器技术的微服务体系怎样选择服务发现、负载均衡的技术实现不同的服务发现的技术有什么区别如何选型

  为了达到松耦合的目的以及基于 DDD 思想微服务之间减少服务调用可以通过哪些技术实现API Gateway 可以用哪些技术框架实现远程调用可以有哪些技术框架怎样提高同步通信的性能?

  分布式的消息队列都有哪些开源、商业实现应该怎样选择适合的消息队列

  使用 DDD 思想应该如何应对服务通信如何在实践中应用 DDD

  分布式存储的隔离级别以及各个 DB 支持的隔离方案的实现原理

  以 MySQL InnoDB 中的 MVCC 为例看并发控制的在 MySQL 的实现学习存储系统对于分布式事务的实现思想。

  了解分布式系统的一致性有哪些问题以及一致性的几种实现程度的模型线;、顺序一致性及因果一致性、最终一致性

  分布式一致性相关的理论 CAPCA、CP、AP 的相关算法的介绍以及适合用于哪些实践

  介绍强一致性的实践二阶段、三阶段。2PC、3PC 的优缺点和限制XA 协议的介绍和实践方案以及最终一致性实践TCC 模型和实践方案

  介绍共识算法和全局消息广播的实现公式算法的基础leader 选举和 quorum 算法以及一些已实现的算法的介绍和对比VSR、Raft、Paxos、ZAB

  共识算法在微服务体系的应用场景介绍服务发现、一致性 kv 存储Etcd、Zk以及技术的选型如何权衡一致性的追求和性能。

  了解了很多分布式的问题和解决方案之后回归微服务架构模型、技术选型、再回顾下微服务的弊端和特点

  微服务体系的架构要素分析安全、伸缩性、性能、可用性、扩展性

  如果你是一位开发工程师相信阅读完本系列课程将会了解很多分布式系统的理论知识同时也会理解一些分布式存储、中间件技术的原理对工作中的分布式架构会有体系化的清晰认知。

  如果你是一位架构师本系列课程提供了对于分布式系统问题的全面梳理以及一些技术背后的理论结合实践和目前业界先进的方案对于技术选型和架构搭建提供了参考。

  无论是 SOA 或者微服务架构都是必须要面对和解决一些分布式场景下的问题。如果只是单服务、做个简单的主备那么编程则会成为一件简单幸福的事只要没有 bug一切都会按照你的预期进行。然而在分布式系统中如果想当然的去按照单服务思想编程和架构那可能会收获很多意想不到的“惊喜”网络延迟导致的重复提交、数据不一致、部分节点挂掉但是任务处理了一半等。在分布式系统环境下编程和在单机器系统上写软件最大的差别就是分布式环境下会有很多很“诡异”的方式出错所以我们需要理解哪些是不能依靠的以及如何处理分布式系统的各种问题。

  微服务架构跟 SOA 一样也是服务化的思想。在微服务中我们倾向于使用 RESTful 风格的接口进行通信使用 Docker 来管理服务实例。我们的理想是希望分布式系统能像在单个机器中运行一样就像客户端应用再坏的情况用户只要一键重启就可以重新恢复然而现实是我们必须面对分布式环境下的由网络延迟、节点崩溃等导致的各种突发情况。

  在决定使用分布式系统或者微服务架构的时候往往是因为我们希望获得更好的伸缩性、更好的性能、高可用性容错。虽然分布式系统环境更加复杂但只要能了解分布式系统的问题以及找到适合自己应用场景的方案便能更接近理想的开发环境同时也能获得伸缩性、性能、可用性。

  分布式系统从结构上来看是由多台机器节点以及保证节点间通信的网络组成所以需要关注节点、网络的特征。

  如果系统中的某个节点挂掉了但是其他节点可以正常提供服务这种部分失败不像单台机器或者本地服务那样好处理。单机的多线程对象可以通过机器的资源进行协调和同步以及决定如何进行错误恢复。但在分布式环境下没有一个可以来进行协调同步、资源分配以及进行故障恢复的节点部分失败一般是无法预测的有时甚至无法知道请求任务是否有被成功处理。

  所以在开发需要进行网络通讯的接口时RPC 或者异步消息需要考虑到部分失败让整个系统接受部分失败并做好容错机制比如在网络传输失败时要能在服务层处理好并且给用户一个好的反馈。

  网络是机器间通信的唯一路径但这条唯一路径并不是可靠的而且分布式系统中一定会存在网络延迟网络延迟会影响系统对于“超时时间”、“心跳机制”的判断。如果是使用异步的系统模型还会有各种环节可能出错可能请求没有成功发出去、可能远程节点收到请求但是处理请求的进程突然挂掉、可能请求已经处理了但是在 Response可能在网络上传输失败如数据包丢失或者延迟而且网络延迟一般无法辨别。

  即使是 TCP 能够建立可靠的连接不丢失数据并且按照顺序传输但是也处理不了网络延迟。对于网络延迟敏感的应用使用 UDP 会更好UDP 不保证可靠传输也不会丢失重发但是可以避免一些网络延迟适合处理音频和视频的应用。

  分布式系统的节点间没有共享的内存不应理所当然认为本地对象和远程对象是同一个对象。分布式系统也不像单机器的情况可以共享同一个 CPU 的信号量以及并发操作的控制也没有共享的物理时钟无法保证所有机器的时间是绝对一致的。时间的顺序是很重要的夸张一点说假如对于一个人来说从一个时钟来看是 7 点起床、8 点出门但可能因为不同时钟的时间不一致从不同节点上来看可能是 7 点出门、8 点起床。

  在分布式环境下开发需要我们能够有意识地进行问题识别以上只是举例了一部分场景和问题不同的接口实现会在分布式环境下有不同的性能、扩展性、可靠性的表现。下面会继续上述的问题进行探讨如何实现一个更可靠的系统。

  对于上述分布式系统中的一些问题可以针对不同的特征做一些容错和处理下面主要看一下错误检测以及时间和顺序的处理模型。在实际处理中一般是综合多个方案以及应用的特点。

  节点的部分失败可以通过增加错误检测的机制自动检测问题节点。在实际的应用中比如有通过 Load Balancer自动排除问题节点只将请求发送给有效的节点。对于需要有 Leader 选举的服务集群来说可以引入实现 Leader 选举的算法如果 Leader 节点挂掉了其余节点能选举出新的 Leader。实现选举算法也属于共识问题在后续文章中会再涉及到几种算法的实现和应用。

  网络问题由于网络的不确定性比较难说一个节点是否真正的“在工作”有可能是网络延迟导致的错误通过添加一些反馈机制可以在一定程度确定节点是否正常运行比如

  健康检查机制一般是通过心跳检测来实现的比如使用 Docker 的线c;Consul、Eureka 都有健康检查机制当发送心跳请求发现容器实例已经无法回应时可以认为服务挂掉了但是却很难确认在这个 Node/Container 中有多少数据被正确的处理了。

  如果一个节点的某个进程挂了但是整个节点还可以正常运行。在使用微服务体系中是比较常见的一台机器上部署着很多容器实例其中个容器实例即相当于刚才描述挂掉的进程挂掉了可以有一个方式去通知其他容器来快速接管而不用等待执行超时。比如 Consul 通过 Gossip 协议进行多播关于 Consul可以参考这篇Docker 容器部署 Consul 集群内容。在批处理系统中Hbase 也有故障转移机制。

  在分布式系统中时间可以作为所有执行操作的顺序先后的判定标准也可以作为一些算法的边界条件。在分布式系统中决定操作的顺序是很重要的比如对于提供分布式存储服务的系统来说Repeated Read 以及 Serializable 的隔离级别需要确定事务的顺序以及一些事件的因果关系等。

  不同机器的 time-of-day 一般也不同就算使用NTP同步所有机器时间也会存在毫秒级的差NTP 本身也允许存在前后 0.05% 的误差。如果需要同步所有机器的时间还需要对所有机器时间值进行监控如果一个机器的时间和其他的有很大差异需要移除不一致的节点。因为能改变机器时间的因素比较多比如无法判断是否有人登上某台机器改变了其本地时间。

  在分布式系统中因为全局时钟很难实现并且像 NTP 同步过程也会受到网络传输时间的影响一般不会使用刚才所述的全局同步时间当然也肯定不能使用各个机器的本地时间。对于需要确认操作执行顺序的时候不能简单依赖一个基于time-of-day的 timestamps所以需要一个逻辑时钟来标记一些事件顺序、操作顺序的序列号。常见的方式是给所有操作加上递增的计数器。

  这种所有操作都添加一个全局唯一的序列号的方式提供了一种全局顺序的保证全局顺序也包含了因果顺序一致的概念。关于分布式一致性的概念和实现会在后续文章详细介绍我们先将关注点回归到时间和顺序上。下面看两种典型的逻辑时钟实现。

  Lamport 实现的核心思想就是把事件分成三类节点内处理的事件、发送事件、接收事件

  所以可见Lamport 时间戳是一种逻辑的时间戳其可以表示全局的执行顺序但是无法识别并发以及因果顺序并发情况无法很好地处理偏序。

  本文引出了一些分布式系统的常见问题以及一些基础的分布式系统模型概念微服务的架构目前已经被更广泛得应用但微服务面临的问题其实也都是经典的分布式场景的问题。本文在分布式系统的问题中主要介绍了关于错误检测以及时间和顺序的处理模型。

  关于时间和顺序的问题处理中没有一个绝对最优的方案Cassandra 使用了全局时钟以及 LWW 处理顺序判定Dynamo 使用了 Vector clock 发现冲突加上 Quorum 算法处理事件并发。这两个存储系统都有很多优秀的分布式系统设计和思想在后续文章中会更详细的介绍数据复制、一致性、共识算法等。

  微服务架构下很适合用 DDDDomain-Drive Design思维来设计各个微服务使用领域驱动设计的理念工程师们的关注点需要从 CRUD 思维中跳出来更多关注通用语言的设计、实体以及值对象的设计。至于数据仓库会有更多样化的选择。分布式系统中数据存储服务是基础微服务的领域拆分、领域建模可以让数据存储方案的选择更具灵活性。

  不一定所有的微服务都需要有一个底层的关系型数据库作为实体对象实例的存储。以一个简单的电商系统为例“用户微服务”和“商品微服务”都分别需要关系型数据库存储结构化的关联数据。但比如有一个“关联推荐微服务“需要进行用户购买、加购物车、订单、浏览等多维度的数据整合这个服务不能将其他所有订单用户、商品等服务的数据冗余进来这种场景可以考虑使用图形数据库。又比如有一个“验证码微服务”存储手机验证码、或者一些类似各种促销活动发的活动码、口令等这种简单的数据结构而且读多写少不需长期持久化的场景可以只使用一个 K-V键值对数据库服务。

  本文先简单介绍下适合微服务架构体系的一些分布式数据存储方案然后深入介绍下这些存储服务的数据结构实现知其然知其所以然。后续文章会继续介绍分布式数据存储的复制、分区。

  不同的数据存储引擎有着不同的特征也适合不同的微服务。在做最初的选型时需要先根据对整体业务范围的判断选择尽量普适于大多数微服务的存储。例如初创型企业需要综合考虑成本节约以及团队的知识掌握度等问题MySQL 是比较常见的选择电商类型的微服务应用更适合 InnoDB 引擎事务、外键的支持、行锁的性能虽然 InnoDB 的读性能会比 MyISAM 差但是读场景有很多可以优化的方案如搜索引擎、分布式缓存、本地缓存等。

  下面会以不同场景为例整理一部分常用的数据存储引擎实际的企业应用中会针对不同场景、服务特征综合使用多种存储引擎。

  存储结构化数据以及需要更多维度关联需要给用户提供丰富的实时查询场景时应该使用关系型数据库。从开源以及可部署高可用性集群的方面来看MySQLPostgreSQL都是不错的选择。PostgreSQL 的历史更为悠久两者都有很多大互联网公司如 Twitter、Facebook、Yahoo 等部署着大规模分布式存储集群集群的复制、分区方案会在后续文章详细介绍。

  NoSQL 即 Not only SQL其概念比关系型数据库更新NoSQL 为数据的查询提供了更灵活、丰富的场景。下面简单列举了一些 NoSQL 数据库及其应用场景。工程师不一定需要掌握所有的 NoSQL 数据库的细节对于不同的领域模型的设计能有更多的灵感会更好。

  目前比较流行的键值存储服务有RedisMemcached以及上篇文中提到的Dynamo。其中 Redis 有 Redis Cluster 提供了支持 Master 选举的高可用性集群。Dynamo 也有分布式高可用集群基于 Gossip 协议的节点间故障检测以及支持节点暂时、永久失效的故障恢复这两者为了保证高可用以及性能牺牲了强一致性的保证但是都支持最终一致性。Memcached 提供了高性能的纯基于内存的 KV 存储并且提供 CAS 操作来支持分布式一致性但 Memcached 没有官方提供的内置集群方案需要使用一些代理中间件如Magento来部署集群。

  在现实世界中一个图形的构成主要有“点”和“边”在图形数据库中也是一样只不过点和边有了抽象的概念“点”代表着一个实体、节点“边”代表着关系。开源的Neo4j是可以支持大规模分布式集群的图形数据库。一般被广泛用于道路交通应用、SNS 应用等Neo4j 提供了独特的查询语言CypherQueryLanguage。

  文档数据库一般都是很少有数据间的关联的图形数据库就是为了让你快速查询一切你想要的关联。如果想更进一步了解 Neo4j可以直接下载Neo4j 桌面客户端一键启动、然后在浏览器输入就可以用起来了。

  列族数据库一般都拥有大规模的分布式集群可以用来做灵活的数据分析、处理数据报表尤其适合写多读少的场景。列族和关系型数据库的差别从应用角度来看主要是列族没有 Schema 的概念不像关系型数据库需要建表的时候定义好每个列的字段名、字段类型、字段大小等。

  在了解了一些分布式数据存储的产品之后为了能更深地理解下面会对分布式存储引擎的一些常用数据结构做进一步介绍。一台计算机可以作为数据存储的地方就是内存、磁盘。分布式的数据存储就是将各个计算机Node的内存和磁盘结合起来不同类型的存储服务使用的核心数据结构也会不同。

  哈希表是一种比较简单 K-V 存储结构通过哈希函数将 Key 散列开Key 哈希值相同的 Value 一般会以单链表结构存储。哈希表查找效率很高常用于内存型存储服务如 Memcached、Redis。Redis 除了哈希表因为其支持的操作的数据类型很多所以还有像 Skiplist、SDS、链表等存储结构并且 Redis 的哈希表结构可以通过自动再哈希进行扩容。

  哈希表一般存储在内存中随着哈希表数据增多会影响查询效率并且内存结构也没法像磁盘那样可以持久化以及进行数据恢复。Redis 默认提供了RDB持久化方案定时持久化数据到 RDB。用 RDB 来做数据恢复、备份是很合适的方案但是因为其定期执行所以无法保证恢复数据的一致性、完整性。Redis 还支持另一种持久化方案——基于AOFAppend only File方式对每一次写操作进行持久化AOF 默认不启用可以通过修改启用AOF 增加了 IO 负荷比较影响写性能适合需要保证一致性的场景。

  在我们平常在 Linux 上分析日志文件的时候比如用 grep、cat、tail 等命令其实可以想象成在 Query 一个持久化在磁盘的 log 文件。我们可以用命令轻松查询以及分析磁盘文件查询一个记录的时间复杂度是 O(n) 的线;因为要遍历文件查询两个记录就是 2*O(n)并且如果文件很大我们没法把文件 load 到内存进行解析也没法进行范围查询。

  本篇介绍了很多分布式存储服务在实际的开发中需要结合领域服务的特点选择。有的微服务可能只需要一个Neo4j有的微服务只需要 Redis。微服务的架构应该可以让领域服务的存储更加灵活和丰富在选择时可以更加契合领域模型以及服务边界。

  文章后半部分介绍了部分存储服务的数据结构。了解了实现的数据结构可以让我们更深刻理解存储引擎本身。从最简单的 append-only 的文件存储再到哈希表、SSTable、BTree基本涵盖了目前流行的存储服务的主流数据结构。如果想深入理解 LSM-tree可以读一下 BigTable 的那篇经典论文。

  : 特点: 1) all in one(所有模块在一起,技术也不分层), 注:像05年06年那会儿,就是这样,把代码写在jsp里面,那时候还没有分层的概念,把所有的东西都写在一起,这就叫做all in one 2) servlet(jsp) 缺点: 并发量差 容错性差(不具有高可用性) 注:不具有高可用性的意...

  ,为什么?因为在访问量或者QPS没有达到单台机器的性能瓶颈的时候,根本没必要进行

  。那如果业务量上来了,一般会怎么解决呢? 首先考虑的就是机器升级。机器配置的垂直扩展,首先要找到当前...

  SOA全称(Service Oriented Architecture) 中文意思是面向

  仅关注于完成一件任务并很好地完成该任务。在所有情况下,每个任务代表着一个小的业务能力。 以往的应用程序开发中,应用程序都是单体型,在开发和部署上比较方便,但是随着业务的不断增加电工基础开发迭代和性能瓶颈等问题都会增加开发难...

  诞生背景: 在一个不断发展的大型应用中,新的业务需求和功能不断增加,技术也在不断演进,不同团队构建的功能子系统采用的技术

  五花八门,子系统之间的开发、部署和运维模式也存在较大差异。如果企业内部没有统一的

  的定义众说纷纭,因此我摘取了几个描述的比较清晰的定义在这供参考。 1.网飞(Netflix)

  造成影响。同时,对于数据库需要适当的拆分,有可能会违反规范。 Cockcroft defines a microservices architecture as a serv...

  支持本地书签、tab页、历史记录搜索; 集成CSDN搜索结果; 他是一个时间转换工具; 他是一个计算器; 他是。。。,更多功能正在添加中

  器上通俗称为LAMP 特征: 应用程序、数据库、文件等所有的资源都在一台

  器操作系统使用linux,应用程序使用PHP开发,然后部署在Apache上,数据库使用Mysql,汇集各种免费开源软件以及一台廉价

  关注微信公众号「GitChat」和百万IT人共同成长。

  微信添加「GitChat小姐姐」 加入技术交流群领取最新干货福利。

 
标签: 电子邮件
打赏
 
更多>同类资讯
0相关评论

推荐图文
推荐资讯
点击排行
网站首页  |  联系客服  |  网站地图  |  排名推广  |  广告服务  |  RSS订阅  |  违规举报