业务需要做分布式改造,与其说改造还不如说是重新开发。由于业务需求特殊总感觉开发的怪怪的。对于公司开发方式不敢苟同。接下来直接说操作吧:
技术选型:
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 不知道坑怎么样不过想试试)
技术选型就这么多吧。不知道有啥坑。以后准备填坑!