分布式架构的详细说明

一、分布式计算技术的形成
CORBA (Common Object Request Broker Architecture) 是在1992年由OMG(Open Management Group) 组织提出的。那时的分布式应用环境都采用Client/Server架构，CORBA的应用很大程度的提高了分布式应用软件的开发效率。
当时的另一种分布式系统开发工具是Microsoft的DCOM(Distributed Common Object Model)。Microsoft为了使在Windows平台上开发的各种应用软件产品的功能能够在运行时(Runtime)相互调用(比如在Microsoft Word中直接编辑Excel文件)，实现了OLE(Linked and Embedded Object)技术，后来这个技术衍生为COM(Common Object Model)。
随着Internet的普及和网络服务(Web Services)的广泛应用, Browser/Server架构的模式逐渐体现出它的优势。 于是，Sun公司在其Java技术的基础上推出了应用于B/S架构的J2EE的开发和应用平台;Microsoft也在其DCOM技术的基础上推出了主要面向B/S应用的NET开发和应用平台。
二、使用的协议
NET中涵盖的DCOM技术和CORBA一样，在网络传输层都采用TCP/IP协议;也都有自己的IDL规范。所不同的是，在TCP/IP之上，CORBA采用GIOP/IIOP协议，所有CORBA服务器以IIOP通信，形成了ORB软件通道;J2EE的RMI曾经采用独立的通信协议，目前已经改为RMI/IIOP，体现了J2EE的开放性;DCOM也有自己的通信协议(TCP在135端口的服务)，但微软没有公开这个协议的规范;同样，CORBA的IDL采用类C++的定义，是公开的规范;DCOM的IDL的文件虽然是文本形式的，微软没有正式公布它的规范，在使用中，NET的IDL是由开发工具生成的。
三、应用的环境
关于NET，比尔盖茨这样说:“简单地说，NET是以微软的各种产品为开发工具和应用平台， 实现基于XML的网络服务。”由此也可以看出，NET在Microsoft的世界里功能强大，但对于Unix和Linux这些在服务器市场占主要份额的系统，NET显得束手无策。
因此，J2EE显示了它跨平台的优势，为网络服务商提供了很好的面向前端(front-end)的开发和应用平台, 随着网络服务进一步广泛应用和服务集成度的提高, 在网络服务提供商的后台会形成越来越庞大的分布式计算环境, CORBA模块结构更适合后台(back-end)的多种服务, 例如网络服务的计费程序等 因此可以看出, J2EE和CORBA技术在网络服务(Web Services)这片蓝天下, 各自有自己的海洋和陆地。如果在前端(front-end)使用了NET开发平台，那么在后端(back-end)的分布式结构中，DCOM就是理想的选择。
J2EE是纯Java技术，很多测试显示RMI(Java)服务器的响应速度远远低于非Java的CORBA服务器。因此，在一些对数据处理速度和响应时间要求较高的系统开发中，要对RMI和CORBA的性能进行测试对比后再做选择。
四、应用软件的开发和维护
从应用软件的开发过程的角度看, J2EE是完全开放式的平台, 体现为既面向设计人员, 也面向开发人员的规范; CORBA也是一种规范, 但更多体现为中间产品, CORBA产品的提供商才是这种规范的真正执行者, 对应用开发的程序员而言, 只要了解IDL语言的规范, 不必详细知道ORB/GIOP/IIOP的协议细节。NET作为Microsoft在网络环境的主打, 体现为一系列产品化的开发工具, 比如C#, C++, 等。这些开发工具是直接针对应用开发人员的。其实Sun公司提供的J2EE也是由许多软件包(应用API)来面对开发人员的。
从软件开发成本与周期以及软件的维护角度看，J2EE比CORBA有以上优势。
五、应用前景
对于分布式计算技术的架构，不能绝对地说哪一个更好，只能说哪一个更合适。针对不同的软件项目需求，具体分析才是明智的选择。
从宏观市场看，CORBA产品的销售并没有想象那样给CORBA产品提供商带来可观的利润;而J2EE的呼声也高于NET; 随着J2EE中RMI/IIOP与CORBA接口的完善，再加上开发费用的考虑和使用的方便性，J2EE一揽子开放的环境会是人们首先考虑的选择;但CORBA标准的强壮的兼容性，也使这种技术在大型系统开发中会占有一席之地。
关于作者
周斌 北京时力永联科技公司业务咨询和软件外包服务部经理，曾执教于复旦大学计算机科学系, 1994年赴美国Oracle总部参加合作项目, 后就读于加拿大哥伦比亚大学

分布式事务是指 *** 作多个数据库之间的事务，在tomcat下是没有分布式事务的，可以借助于第三方Jotm和Automikos实现，下面就写一个使用Jotm实现分布事务的例子，如有不足，请各位大大指点：

Dao及实现，先写出一个interface再去实现他，可能有些人觉得直接写实现类多好，但我还是建议为了结构清晰，增强代码的可读性，可维护性还是先写接口再去实现的好：

先写一个interface，定义要实现的方法：

实现接口，传入一个String ds来判断调用哪个JdbcTemplate：

service及实现：

还是接口与他的实现：

持久化的 *** 作：

applicationContextxml

基本的spring配置以及Jotm bean;

JTA事务管理器，数据源datasourceA和datasourceB配置:

事务切面配置aop,通知配置以及dao,service配置：

单元测试，在实际项目中就是写一个controller:

对于大型网站而言，随着流量的暴增，单一服务器是无法抗住高并发的，所以大型网站都是从最初的单一架构演变为集群分布式架构。淘宝网作为数一数二的电商平台，它开发了很多底层技术框架以适应日益发展的需要。

什么是分布式与负载均衡？

1、分布式

分布式是将一个完整业务拆分为多个子业务（或者本身就是不同的业务）部署在不同服务器之上，比如用户系统、订单系统、商城系统分布部署在不同服务器上。

还有一个概念容易和分布式混淆，那就是集群。集群强调的是同一个业务部署在多台服务器之上。

集群模式下，多个节点中的某个节点挂了是不会影响整体业务的；而分布式环境下若某个节点挂了则可能会影响某个业务（实际上不会，因为业务分布式部署后也会做集群）。

2、负载均衡

负载均衡充当的角色就是“裁判”，它将大量并发流量分摊至多台节点服务器（集群）上进行处理，这样减少了用户等待响应时间。

所以说负载均衡离不开服务集群。

淘宝如何是如何实现分布式、集群和负载均衡的？

1、动静分离

将动态请求与静态请求分别部署在不同服务器上，以便针对性进行优化。

2、分布式服务框架HSF

HSF是阿里的分布式服务框架，经过拆分，各系统间的耦合度大大降低了，更有利于分布式部署。

3、分布式NoSQL框架Tair

Tair是淘宝开源的分布式K/V数据库。

4、高性能Web服务器Tengine

Tengine是基于Nginx二次开发的，性能上比Nginx更好，而且支持更多特性，如：请求合并、限速模块、内置Lua等。可以借助它来做反向代理和负载均衡。

以上就是我的观点，对于这个问题大家是怎么看待的呢？欢迎在下方评论区交流~我是科技领域创作者，十年互联网从业经验，欢迎关注我了解更多科技知识！

主要提供微服务发布,服务治理和服务监控,因为复杂的业务需求,会造成线上服务的混乱,和连接数据库的混乱。微服务的好处是:1、业务解耦,方便扩容,方便系统按模块升级,模块重用；

2、开发新业务简单,开发人员可以专注某一业务,方便代码管理；

3、方便数据库优化。微服务的坏处，也就是分布式服务框架要解决的问题:1、每个系统之间的关系变得非常复杂；2、随着调用的业务增多,底层的模块需要高可用性和并发；3、需要分布式Session框架支持；4、分层后增加测试复杂度。

秒杀系统的架构设计

秒杀系统，是典型的短时大量突发访问类问题。对这类问题，有三种优化性能的思路：

写入内存而不是写入硬盘

异步处理而不是同步处理

分布式处理

用上这三招，不论秒杀时负载多大，都能轻松应对。更好的是，Redis能够满足上述三点。因此，用Redis就能轻松实现秒杀系统。

用我这个方案，无论是电商平台特价秒杀，12306火车票秒杀，都不是事:)

下面介绍一下为什么上述三种性能优化思路能够解决秒杀系统的性能问题：

1  写入内存而不是写入硬盘

传统硬盘的读写性能是相当差的。SSD硬盘比传统硬盘快100倍。而内存又比SSD硬盘快10倍以上。因此，写入内存而不是写入硬盘，就能使系统的能力提升上千倍。也就是说，原来你的秒杀系统可能需要1000台服务器支撑，现在1台服务器就可以扛住了。

你可能会有这样的疑问：写入内存而不是持久化，那么如果此时计算机宕机了，那么写入的数据不就全部丢失了吗？如果你就这么倒霉碰到服务器宕机，那你就没秒到了，有什么大不了？

最后，后面真正处理秒杀订单时，我们会把信息持久化到硬盘中。因此不会丢失关键数据。

Redis是一个缓存系统，数据写入内存后就返回给客户端了，能够支持这个特性。

2 异步处理而不是同步处理

像秒杀这样短时大并发的系统，在性能负载上有一个明显的波峰和长期的波谷。为了应对相当短时间的大并发而准备大量服务器来应对，在经济上是相当不合算的。

因此，对付秒杀类需求，就应该化同步为异步。用户请求写入内存后立刻返回。后台启动多个线程从内存池中异步读取数据，进行处理。如用户请求可能是1秒钟内进入的，系统实际处理完成可能花30分钟。那么一台服务器在异步情况下其处理能力大于同步情况下1800多倍！

异步处理，通常用MQ(消息队列)来实现。Redis可以看作是一个高性能的MQ。因为它的数据读写都发生在内存中。

3 分布式处理

好吧。也许你的客户很多，秒杀系统即使用了上面两招，还是捉襟见肘。没关系，我们还有大招：分布式处理。如果一台服务器撑不住秒杀系统，那么就多用几台服务器。10台不行，就上100台。分布式处理，就是把海量用户的请求分散到多个服务器上。一般使用hash实现均匀分布。

这类系统在大数据云计算时代的今天已经有很多了。无非是用Paxos算法和Hash Ring实现的。

Redis Cluster正是这样一个分布式的产品。

使用Redis实现描述系统

Redis和Redis Cluster（分布式版本），是一个分布式缓存系统。其支持多种数据结构，也支持MQ。Redis在性能上做了大量优化。因此使用Redis或者Redis Cluster就可以轻松实现一个强大的秒杀系统。

基本上，你用Redis的这些命令就可以了。

RPUSH key value

插入秒杀请求

当插入的秒杀请求数达到上限时，停止所有后续插入。

后台启动多个工作线程，使用

LPOP key

读取秒杀成功者的用户id，进行后续处理。

或者使用LRANGE key start end命令读取秒杀成功者的用户id，进行后续处理。

每完成一条秒杀记录的处理，就执行INCR key_num。一旦所有库存处理完毕，就结束该商品的本次秒杀，关闭工作线程，也不再接收秒杀请求。

要是还撑不住，该怎么办

也许你会说，我们的客户很多。即使部署了Redis Cluster，仍然撑不住。那该怎么办呢？

记得某个伟人曾经说过：办法总比困难多！

下面，我们具体分析下，还有哪些情况会压垮我们架构在Redis（Cluster）上的秒杀系统。

脚本攻击

如现在有很多抢火车票的软件。它们会自动发起>spring cloud，dubbo

paxos算法及其变体的实现，保证分布式一致性。典型的是zookeeper。

kafka。kafka是一个分布式消息队列。具有高性能、持久化、多副本备份、横向扩展能力。生产者往队列里写消息，消费者从队列里取消息进行业务逻辑。一般在架构设计中起到解耦、削峰、异步处理的作用。
kafka对外使用topic的概念，生产者往topic里写消息，消费者从读消息。为了做到水平扩展，一个topic实际是由多个partition组成的，遇到瓶颈时，可以通过增加partition的数量来进行横向扩容。单个parition内是保证消息有序。
每新写一条消息，kafka就是在对应的文件append写，所以性能非常高。

键值对NoSQL：Redis
列NoSQL：Hbase
文件NoSQL：Mongodb
memcache

mysql

---