为什么要从rpc-service开始?简单的来说,因为一般我先启动的是这个这个模块,它是作为一个provider方的,现将其服务注册到zookeeper服务中心上面去,再由server端的consmer去消费。关于dubbo的相关资料请参考:
http://dubbo.io/
- 1
曾经dubbo有一段时间是没有更新的,应该是今年7,8月份左右吧,dubbo有了自己的官网时候,又开始了它的新活力,持续关注。题外话了,继续
在上一篇的“zheng项目系统简单的分析记录”中我写到,这块主要是实现类。各种的impl,和mapper.xml。我加了xml,不是那个mapper(dao),dao模块的那个mapper才真的是dao。没办反,习惯了controller,service,serviceImpl,dao,daoImpl(xml)是我“长期”以来的习惯。这个模块我觉得主要是配置文件了。
1. applicationContext-dubbo-provide
注册中心的name,address,port等信息的设置,服务的暴露,再看一眼双方是怎么写的:
提供方:
<!-- 用户 -->
<bean id="upmsUserService" class="com.zheng.upms.rpc.service.impl.UpmsUserServiceImpl"/>
<dubbo:service interface="com.zheng.upms.rpc.api.UpmsUserService" ref="upmsUserService" timeout="10000"/>
- 1
- 2
- 3
- 4
消费者:
<!-- 用户 -->
<dubbo:reference id="upmsUserService" interface="com.zheng.upms.rpc.api.UpmsUserService" mock="true"/>
- 1
- 2
也可以直接用注解的方式,实现类用@Service(com.alibaba.dubbo.config.annotation.Service)来注册服务,用@Reference(com.alibaba.dubbo.config.annotation.Reference)来消费,不过我没去试啊,之后我仿写的时候会拿来尝试,看看有没有坑,应该没有吧,哈哈。喜欢注解的方式,简单快,
- applicationContext-jdbc
这里我注意到的是事务的配置,因为这个部分处理的大部分是业务相关的内容
<tx:annotation-driven transaction-manager="transactionManager"/>
- 1
我之前的写法是下面的这个样子的,没有用@Transactional:
<tx:advice id="txAdvice" transaction-manager="transactionManager">
<tx:attributes>
<tx:method name="delete*" propagation="REQUIRED" read-only="false" />
<tx:method name="insert*" propagation="REQUIRED" read-only="false" />
<tx:method name="update*" propagation="REQUIRED" read-only="false" />
<tx:method name="save*" propagation="REQUIRED" read-only="false" />
</tx:attributes>
</tx:advice>
<aop:aspectj-autoproxy proxy-target-class="true"/>
<!-- 事务处理 -->
<aop:config>
<aop:pointcut id="pc" expression="execution(* com.ts.common.service..*(..))" />
</aop:config>
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
我之前的做法是直接指定mapper(dao)包的位置,没有去直接,所以这点和命名方式也是有很大的关系的,如果命名没统一的话,也没法这么爽,直接**.mapper。当然,不可能哪个公司或者项目没有这种规范。
ZhengUmpsRpcServiceApplication
刚学web工程的时候,没有这种rpc概念,模块化概念和接触这方面工程概念的时候,都是把server和这个放在一个模块里面,一起启动,要挂一起挂了。也是很通俗的做法吧,很好又get一招,无非是打包打打两次,自动化部署目前还是算了,个人觉得小项目自己打包发布也不慢,大项目的话有自己的运维这种事情没必要我这个后端去担心这些问题。这块总结就是,接口给你写了,丢在服务中心里面,你要就去调用。
pom文件
- 切换不同的配置文件,这个问题不在于这种方式,在于和assembly插件结合的方式
我以前有个工程,我那个时候没接触过assembly这种插件,不知道有这种东西(比较菜鸡,见谅),当时程序也是这种启动main函数的方式启动的,自己写的sh脚本,MAIN_CLASS启动main函数(你懂那种启动脚本吗,没有tomcat,没用jetty这种东西?有兴趣的私聊我我可以给看看pom和那个sh文件,打包是rpm,不过也有好处,没去写这个之前,我一直不知道args[]居然还可以这么玩)。以前写的那种方式麻烦,的确麻烦了不止一点点。用assembly生成的bin文件里面的sh有点缺憾。我希望的是有start_dev.sh,start_test.sh,start_prod.sh,start_uat.sh这种脚本一起生成出来,你懂我意思吧!而不是根据profile的那个直接生成。讲道理,应该是可以的,不过,我目前还是不知道怎么去实现,知道的朋友麻烦告诉我,多谢。
<profiles>
<profile>
<id>dev</id>
<properties>
<env>dev</env>
</properties>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
</profile>
<profile>
<id>test</id>
<properties>
<env>test</env>
</properties>
</profile>
<profile>
<id>prod</id>
<properties>
<env>prod</env>
</properties>
</profile>
</profiles>
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptor>src/main/assembly/assembly.xml</descriptor>
</configuration>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
这部分的东西不是太多,大牛都不用细看,扫扫应该差不多就能搞懂个百分之78十,rpc-api我是不打算去说什么,一堆接口,rpc-service里的impl继承它具体实现。dao模块趁着今天没什么事情,阳光正好,我一起写了吧,写的不好见谅。看得人不管是学术严谨还是装波比的,都可以评论下不足之处和说错的地方,我好学习进步,国家要消灭贫困,我再不致富过几年就要被消灭了。继续:
跳过rpc-api直接看dao
上一篇我也说了,就是model和mapper(dao接口),而且基本上我们可以用framemarker直接自动生成,这个部分我在上上篇http://blog.csdn.net/u014449653/article/details/78294862中已经说了怎么快速生成,具体内容不再做相关阐述。接下来是大头了,server。这个模块的点可能会比较的多,它本身就是一个web工程……内容有点多哈,下一篇“进击zheng项目zheng-umps-server”会继续叨叨。
国际惯例:
原项目地址:https://gitee.com/shuzheng/zheng (这次从github切换成了码云的了)