白癜风能够治愈吗 http://disease.39.net/bjzkbdfyy/170807/5602607.html点击上方蓝色字体，选择“标星
存在问题:
1:模块之间耦合度太高,其中一个功能升级,其他的模块都得一起升级部署。
2:开发困难,各个团队开发最后都要整合在一起.
3:系统扩展性差
4:不能灵活进行分布式部署
解决方案：
把模块才分成独立的工程,单节点运行,如果某一个节点压力大了可以单独对这个节点进行增加配置,其他节点不受影响。缺点就是系统之间交互
需要额外的工作量来进行接口的开发。把系统拆分成多个工程,需要完成系统的工程需要多个工程协作完成,这种形式就叫做分布式。分布式:
把系统拆分成多个子系统.优点:
1:把模块拆分,使用接口通信,降低模块之间的耦合度.
2:把项目拆分成若干个子项目,不同的团队负责不同的子项目.
3:增加功能时只需要再增加一个子项目,调用其他系统的接口就可以。
4:可以灵活的进行分布式部署.
5:提高代码的复用性,比如service层,如果不采用分布式rest服务方式架构就会在手机wap商城,
缺点:系统之间的交互要使用远程通信,接口开发增大工作量,但是利大于弊。
2.2分布式项目拆分垂直拆分：说明:按照项目的功能(业务)模块进行拆分.将不同的业务部署到不同的服务器中.
水平拆分：场景:一个service可能行代码由一个人完成controller-Service-mapper任务繁重.这时需要多个人开发!!概念:按照调用的层级进行拆分.
2.3分布式项目总结分布式项目:对外统一,对内独立.实现了架构的解耦
2.3分布式事务1、分布式事务和分布式锁？比如从支付宝转元到余额宝，我们又两个方法1、支付宝减掉，2、余额宝加上。传统的在一个模块，一个服务，或者一个方法里面，我们就很好解决了，只需要注解一个事务就行了。
Transactional(rollbackFor=Exception.class)这样我们就可以保证两个方法数据的一致性了。但是显然，现在我们的项目中，为了满足性能要求，不可能还这样传统单机实现。我们做成了两个服务，在两个不同的模块1、支付宝，2、余额宝这样就存在了我们提到的问题，分布式事务，这个时候如何解决呢？
通常来说呢实现方式有如下几种：1、两阶段提交协议（Two-phaseCommit，2PC）：架构图
简单来说，协调器先给A/B各发一条，准备的命令，等到都返回准备好了的命令的时候，再发起事务提交。这样来保证事务一致性，但是存在很多问题，就是通信上中断的情况，会导致事务一致无法提交，而可能使系统崩溃。这就可以使用第二种方案。第二种方案：TCC补偿性，分为三个阶段TRYING-CONFIRMING-CANCELING。每个阶段做不同的处理。TRYING：阶段主要是对业务系统进行检测及资源预留CONFIRMING：阶段是做业务提交，通过TRYING阶段执行成功后，再执行该阶段。（默认如果TRYING：阶段执行成功，CONFIRMING就一定能成功。）CANCELING：阶段是回对业务做回滚，在TRYING阶段中，如果存在分支事务TRYING失败，则需要调用CANCELING将已预留的资源进行释放。
什么是分布式锁？场景1：常规的我们多线程访问同一代码块的时候，为了保证同一时间只能由一个线程访问，保证数据安全一致性，通常我们使用synchronized关键字来对方法加锁，以达到保证数据安全性。
场景2：现在越来越多的项目，为了追求性能与高并发，采用了soa架构，微服务架构，于是就会出现多个模块单独的服务。这个时候呢就会有一个问题，如何保证多个节点的现场同步执行呢？这种情况呢，就会用到了分布式锁。分布式锁的解决方案与实现有哪些呢？1、数据库解决方案思路：a.数据库建一张表，字段方法名并且作为唯一性，当一个方法执行时插入，则相当于获得锁，其他线程将无法访问，方法执行完则释放锁。但是上面这种存在问题：1、数据库单点，出现故障则将导致系统不可用。2、没有失效时间，一旦操作方法异常，导致一直没有解锁，也将导致其他不可用用。b.使用select*fromuseruwhereusername="forupdate来对记录加上排他锁。操作完成后使用
