打怪升级之路——分布式实践之技术选型。

业务需要做分布式改造，与其说改造还不如说是重新开发。由于业务需求特殊总感觉开发的怪怪的。对于公司开发方式不敢苟同。接下来直接说操作吧：

技术选型：

1.1 项目管理工具

Maven、Nexus私服搭建（为了使用第三方包）

1.2 web服务器

Nginx 、Tomcat （Maven Tomcat Plugin）

1.3 业务框架

Spring 、Spring MVC、MyBatis

1.3.1 Springmvc和Struts2区别

Springmvc和Struts2区别：与Spring框架天生整合，无框架兼容问题，与Struts2相比安全性高，配置量小、开发效率高。springmvc面向方法开发的（更接近service接口的开发方式），struts2面向类开发。springmvc可以单例开发，struts2只能是多例开发。

1.3.2 Mybatis和Hibbernate区别

Mybatis： 小巧、方便、高效、简单、直接、半自动化

Hibernate：强大、方便、高效、复杂、间接、全自动化

 

1.4 RPC框架

Dubbo、Zookeeper

1.4.1 Dubbo是什么？

Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。简单的说，dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有dubbo这样的分布式服务框架的需求，并且本质上是个服务调用的东东，说白了就是个远程服务调用的分布式框架（告别Web Service模式中的WSdl，以服务者与消费者的方式在dubbo上注册）

其核心部分包含:
1) 远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。
2) 集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。
3) 自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

1.4.2 Dubbo能做什么？

1) 透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。     
2)服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。
3)Dubbo采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载。

1.4.3 Zookeeper在Dubbo中的作用是什么？

发布与订阅模型，即所谓的配置中心，顾名思义就是发布者将数据发布到ZK节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，服务式服务框架的服务地址列表等就非常适合使用。

 

1.5 数据库

1.5.1 关系型数据库

Mysql 5.7  

1.5.2 非关系型数据库

Redis

======================================================简陋的分割线==========================================================

对这个中规中矩的选型，也没啥亮点。也不是最新的。但是更贴合目前的开发团队和开发实力。

就是数据库中间件 要用Mycat啃了一周书没看源码，心里没底，但是又让开发框架。忙忙的，最后再说数据库吧。

另外我心里最想用：springboot  ，beetlsql  ，shiro ，（springcolud 不知道坑怎么样不过想试试）

技术选型就这么多吧。不知道有啥坑。以后准备填坑！