.NET分布式系统架构思路

  分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。分布式系统的出现是为了用廉价的、普通的机器完成单个计算机无法完成的计算、存储任务。其目的是利用更多的机器,处理更多的数据。

一、最初假设的网站中,我们把应用系统网站、文件和数据库都放在一台服务器上,一台服务器包打天下。

二、随着业务扩展,一台服务器无法满足性能需求,将应用程序、数据库、文件分别部署在不同的服务器上,并根据服务器用途不同,配置不同的硬件,达到性能最佳的效果。

三、随着业务扩展,一台数据库、网站、文件服务器再高性能也无法大量数据处理、高并发用户访问时,必须考虑采用集群方式。

1、应用服务器作为网站的入口,会承担大量的请求,我们往往通过应用服务器集群来分担请求数。应用服务器前面部署负载均衡服务器调度用户请求,根据分发策略将请求分发到多个应用服务器节点。常用的负载均衡技术硬件的有F5,价格比较贵,软件的有LVS、Nginx、HAProxy等。

2、随着用户量的增加,数据库成为最大的瓶颈,改善数据库性能常用的手段是进行读写分离以及分表,读写分离顾名思义就是将数据库分为读库和写库,通过主备功能实现数据同步。分库分表则分为水平切分和垂直切分,水平切换则是对一个数据库特大的表进行拆分,例如订单、物流信息表等。垂直切分则是根据业务不同来切换,如订单、计税等等不同的主题放在不同的数据库中。这种情况下,关联查询是没有的,通过程序可以比较容易的去解决,还有就是采用分布式事务,来保证数据的一致性。我们这里还有一个做法,一个大的数据表拆分为当前操作表和历史记录表, 当前操作表只保留正在操作的数据,完成后转入历史记录表,这样可以提高当前操作数据的效率。

3、用户一天天增加,业务量越来越大,产生的文件越来越多。通常情况下,一个目录下的文件建议不能超过1万个,否则对于文件的查找和轮询都会非常慢,会导致整个系统无法正常运行。我们一般是按照"\应用程序名\模块名称\日期"的目录结构组织的,对于文件数目仍旧很大的应用,应该再细分。当单台的文件服务器已经不能满足需求,就需要分布式的文件系统支撑。常用的分布式文件系统有NFS。我们用的是MS的分布式文件系统(DFS),与AD域相关性较大。

4、因为应用服务器是集群方式,用户前后两次请求可能访问的不是一台服务器。因此已经不能像以前一样使用状态(Application、Session、Cache、ViewState等),应用系统必须是无状态的(当然了,用的负载均衡具有会话保持的时候,一个用户只会定位到一台服务器)。系统的缓存应该保存在专门的缓存服务器上,如果必须有状态,也应该保存在专门的缓存服务器中。作为第一批吃螃蟹者,我们用了微软的AppFabric作为缓存服务器,因为当时版本很低,问题也不少,后来我们弃用了AppFabric,使用Redis作为缓存服务。现在,AppFabric已经改进了不少,运行在Azure云上,应该是不会存在以前的问题了。

中间插一段啊。对于各种政府、单位等不能将系统部署到互联网的部门,并且在各省、市都有对应的分支机构。因为网络专线的价格还是比较高的,至少比互联网的网络带宽低了不少,当然了不差钱的不说啊。这种情况下,一般不采用如上的集中式、集群部署方式,而是采用分布式部署的方式,第一种分布式部署是各分支机构搭建一整套系统,定期(例如每天)进行数据的同步工作,将分支数据汇总到总部、总部的数据下发回各分部;第二种分布式部署方式是各分支部署中间件,但是数据集中在总部。

四、随着业务进一步扩展,应用程序变得非常臃肿,这时我们需要将应用程序进行业务拆分。

  如我们做的综合业务管理系统分为门户、联系处置、业务信息、指标、数据查询分析等业务板块。每个业务板块是一个独立的应用负责相对独立的业务运作。业务板块之间通过消息队列进行通信来实现。数据库也进行相应的拆分,不同的主题放到不同的数据库中。同时,最好搭建静态资源服务器,将公用的css、js、images等都存放到静态资源服务器中。

五、对于海量数据的查询,我们使用nosql数据库加上搜索引擎可以达到更好的性能。

  常用的NOSQL有mongodb和redis,搜索引擎有lucene,我们使用的Solr、ElasticSearch等基于Lucene内核实现的更易用的搜索引擎。数据量大的话,Solr等也要做成集群。

六、再往下走,系统需要与其他系统进行交互,系统也要给各种前端(例如网站、安卓、IOS)提供服务,这样我们就要在逻辑层之上建设应用服务层,提供对客户端的和对外的SOA服务接口。这样又涉及到DTO、WebService、WCF和WebApi(Rest)等概念。但是最重要的是,SOA方式下,包括前面的MQ方式下,事务一致性无法得到保障的,必须采用一定的机制例如事务补偿机制来确保事务的最终一致性。各个业务板块所在的服务器,在不同时段的压力也不同,为了尽量做到服务器集群内各服务器的压力平摊, 还需要提供更好的机制,记录下每个服务器的压力、资源情况、连接数等等,以便将新的请求转向到压力最小的服务器上。

七、业务继续发展,就是CDN,再往下就是搭建几个中心,将系统部署在各个中心,各地用户访问距离他最近的中心,中心间数据保持同步。

八、上面讲了应用系统方面比较多,数据方面也要做许多工作。上面已经介绍了分库分表方式。应用系统做大了,势必有许多的数据资源,尤其是现在大数据这个名词非常火爆的情况下,数据分析和处理是一个系统必须要做的事情。这样做的好处是,将数据的查询、分析等独立出来,不影响正式运行中的系统,另外是通过分析挖掘确实能得到许多意想不到的价值。

这时,主要的工作是搭建数据仓库,然后进行后续的分析和处理。使用ETL/ELT将数据定期从正式环境中导入到数据仓库中,按照不同的主题搭建一个个的数据集市。对于数据量比较小的系统,可以使用关系数据库+多维数据库的方式;对于大型系统,就要使用按列存储、并行数据库等方式了。对于数据的分析可以以报表、KPI、仪表盘驾驶舱等方式提供上层领导决策,也可以使用数据挖掘、机器学习和训练等方式实现价值发现、风险控制等。

九、一般情况下,企业是没有那么大的财力和人员去做上述内容的,因此使用云成为企业的一个选择。无论是Azure、阿里云、亚马逊等都会提供一个个的服务。我们就以阿里云为例,ECS提供虚拟服务器、SLB提供负载均衡、RDS提供数据库服务、OSS提供存储服务、DRDS是分布式数据服务、ODSP(现在改名叫MaxCompute)提供大数据的计算服务、RocketMQ提供MQ、OCS提供分布式缓存服务、以及CDN、OTS、ADS等等就不一一列举了。

对了,现在还有Docker这个利器,无论在企业还是云中都可以使用,我们在自己内部使用的Redis、Memcached、RabbitMQ、Solr等都部署在Docker中,确实比较方便。

原文地址:https://www.cnblogs.com/hghg/p/10449793.html

时间: 2024-10-11 03:43:53

.NET分布式系统架构思路的相关文章

分布式系统的架构思路

一.前言 在计算机领域,当单机性能达到瓶颈时,有两种方式可以解决性能问题,一是堆硬件,进一步提升配置,二是分布式,水平扩展.当然,两者都是一样的烧钱.今天聊聊我所理解的分布式系统的架构思路. 二.分布式系统的两种方式 平时接触到的分布式系统有很多种,比如分布式文件系统,分布式数据库,分布式WebService,分布式计算等等,面向的情景不同,但分布式的思路是否是一样的呢? 1.简单的例子 假设我们有一台服务器,它可以承担1百万/秒的请求,这个请求可以的是通过http访问网页,通过tcp下载文件,

基于Dubbo的分布式系统架构完整教程

1课程介绍20分钟2使用Dubbo对传统工程进行服务化改造的思路介绍15分钟3使用Dubbo对传统工程进行服务化改造55分钟4ZooKeeper注册中心安装29分钟5使用Dubbo对传统工程进行服务化改造后的服务调用测试19分钟6使用Dubbo进行规模服务化前的工程结构优化35分钟7Dubbo管理控制台的安装21分钟8使用Maven构建Dubbo服务的可运行jar包46分钟9在Linux操作系统上手工部署Dubbo服务50分钟10构建Dubbo服务消费者Web应用的war包并在Tomcat中部署

基于Dubbo的分布式系统架构视频教程

一.基础篇第001节--课程介绍第01节--使用Dubbo对传统工程进行服务化改造的思路介绍第02节--使用Dubbo对传统工程进行服务化改造第03节--ZooKeeper注册中心安装第04节--使用Dubbo对传统工程进行服务化改造后的服务调用测试第05节--使用Dubbo进行规模服务化前的工程结构优化第06节--Dubbo管理控制台的安装第07节--使用Maven构建Dubbo服务的可运行jar包第08节--在Linux操作系统上手工部署Dubbo服务第09节--构建Dubbo服务消费者We

基于Dubbo的分布式系统架构实战

本套课程完整高清,需要的同学联系我,需要的速度了.联系Q 2929608935 01节:课程介绍02节:使用Dubbo对传统工程进行服务化改造的思路介绍03节:使用Dubbo对传统工程进行服务化改造04节:ZooKeeper注册中心安装05节:使用Dubbo对传统工程进行服务化改造后的服务调用测试06节:使用Dubbo进行规模服务化前的工程结构优化07节:Dubbo管理控制台的安装08节:使用Maven构建Dubbo服务的可运行jar包09节:在Linux操作系统上手工部署Dubbo服务10节:

分布式系统架构的基本原则和实践(转)

采用分布式系统架构是由于业务需求决定的,若系统要求具备如下特性,便可考虑采用分布式架构来实现: 1.数据存储的分区容错,冗余 2.应用的大访问.高性能要求 3.应用的高可用要求,故障转移 分布式系统遵循几个基本原则 1.CAP原理 CAP Theorem,CAP原理中,有三个要素: 一致性(Consistency) 可用性(Availability) 分区容忍性(Partition tolerance) CAP原理指的是,在分布式系统中这三个要素最多只能同时实现两点,不可能三者兼顾.因此在进行分

Dubbo视频教程《基于Dubbo的分布式系统架构视频教程》----课程列表

Dubbo视频教程官网:http://www.roncoo.com/ 作者:吴水成,邮箱:[email protected] ,QQ:840765167 <基于Dubbo的分布式系统架构视频教程>包含基础篇.高级篇.高可用架构篇,教程以第三方支付项目的系统架构实战经验为背景,最终形成一套分布式系统架构解决方案.教程中涵盖的技术点包括 Dubbo分布式服务.ZooKeeper注册中心.Redis3.0分布式缓存集群.MySQL读写分离集群.FastDFS_v5.05分布式文件系统集群.Activ

基于Dubbo的分布式系统架构实战视频课程

课程介绍:Dubbo是阿里巴巴开源的分布式服务化治理框架(微服务框架),久经阿里巴巴电商平台的大规模复杂业务的高并发考验,到目前为止Dubbo仍然是开源界中体系最完善的服务化治理框架,因此Dubbo被国内大量的的互联网公司和专统企业使用,国内使用Dubbo的企业有:阿里巴巴.京东.当当.携程.去哪儿.搜狐.南方航空.中软国际.软通动力.各大电信运营商等 京东.当当.去哪儿等企业还组建了自己的中间件团队按自己的业务需求对Dubbo进行框架定制,目前当当网已开源了自己的Dubbo定制版Dubbox

(整理三)高并发架构思路,附十万定时任务执行解决方案

一.什么是高并发 高并发(High Concurrency)是互联网分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计保证系统能够同时并行处理很多请求. 高并发相关常用的一些指标有响应时间(Response Time),吞吐量(Throughput),每秒查询率QPS(Query Per Second),并发用户数等. 响应时间:系统对请求做出响应的时间.例如系统处理一个HTTP请求需要200ms,这个200ms就是系统的响应时间. 吞吐量:单位时间内处理的请求数量. QPS:每秒响应

面试官们“乐此不疲”分布式系统架构是什么鬼?

目录: 一.什么是分布式系统? 二.为什么要走分布式系统架构? 三.系统如何进行拆分? 四.分布式之后带来的技术挑战? 一.什么是分布式系统? 在谈分布式系统架构前,我们先来看看,什么是分布式系统? 假设原来我们有一个系统,代码量30多万行.现在拆分成20个小系统,每个小系统1万多行代码. 原本代码之间都是直接基于Spring框架走JVM内存调用,现在拆开来,将20个小系统部署在不同的机器上,然后基于分布式服务框架(比如dubbo)搞一个rpc调用,接口与接口之间通过网络通信来进行请求和响应.