分布式改造剧集1
背景介绍
我所在的项目组，使用的技术一直是接近原始社会的：jdk1.6 + SpringMVC + hessian + Mybatis，当前最火的中间件技术Redis、MQ是完全没有用到，更别说什么分布式这种高大上的东西了。开始一直以为可能接下来的日子我都会在原始社会中渡过，直到我跳槽到另一家公司。
事情总是在最不抱希望的时候出现转机，最近老大指派我牵头做分布式改造。作为技术痴的我，刚接到这个消息的时候别提有多激动了。虽然平时空闲时间会去学习最新的一些技术，但总觉得没怎么学进去。一是年级大了，对于一个东西不用就忘；二是都只是敲一些demo代码，相信各位大神都知道，真正项目中遇到的技术难题永远比demo中的那些小问题复杂的多。
废话不多说，先来说说这次分布式改造的预期：
- 应用的分布式：这一点很容易理解，就是希望以前的单节点应用能够部署成多节点，一个请求可以转发到多个节点中的任意一个
- 缓存的分布式：好在我们项目对缓存的依赖性不是特别高，项目中使用的缓存也大部分仅仅是为了提升效率。对于内存缓存（Ehcache），希望在不同节点间能够同步，对数据的实时性和一致性要求不是特别高
- 锁的分布式：业务互斥其实一直是我们项目的一个复杂所在。因为是金融行业，一旦业务互斥没有做好，就会出现严重的资金风险。对锁的可靠性要求特别高，对于互斥的业务锁，只要一个节点能够拿到，其他节点一定不能拿到。项目以前的实现是直接通过内存中的一个ConcurrentHashMap去实现的。如果多节点部署的话，很显然每个节点都会存在一个内存锁，原来的锁将完全不起作用
当然除了预期之外，考虑到部署环境的复杂性：一共几十套环境，后面可能上百。有的部署在腾讯云上，有的部署在客户自己内部系统中，一个微小的部署变动可能会被放大几十倍。所以领导除了给出预期之外，还给了以下两点要求：
- 尽量不要升级JDK
- 尽量不要引入新的中间件或者新的外部应用部署
好了，背景暂且交代到这里。我们基本对这次分布式改造剧集有了了解，下面开始进入正片……
第一章：纯DIY分布式
第一集： 应用分布式改造
探索之路
对于当今的互联网企业码农，只要公司不处于原始社会。分析了上面的需求之后，对于这种请求多节点转发负载的，很自然地就会想到nginx。没错，我开始也想到了nginx，并且本地测试了，对于当前项目的转发只需下面简单的配置即可：
upstream apps {
server 127.0.0.1:8380;
server 127.0.0.1:8480;
server 127.0.0.1:8580;
}
server {
listen 9999;
server_name 127.0.0.1:9999;
#本机的hessian服务最终都发布成 */service/*.hs的形式
location /service/ {
proxy_pass http://apps/myapp-war/;
}
} 但是各位别忘了要求的第二点，好吧？忘了的话请再次回头看上面
版权声明：本文为Kidezyq原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。