今天完成的事情：完成任务九

明天计划的事情：总结一下做过的任务，弄复盘的事情

遇到的问题：各种jar包冲突

收获：

composite文件

spring配置文件

开启远程访问服务注解

报错说我没有注解

查看扫描注解的文件，并没有注解了@Remotable的service接口

..从昨天卡到今天卡了一天。少了jar包。我少了第二个

启动客户端，报错

百度说是重复扫描

http://blog.csdn.net/haoyifen/article/details/51172647

是因为这样吗：

这里扫描了一次，注册了bean

这里又注册了一次

...

先做个不连接数据库的

服务端hello实现类

spring配置文件

composite文件

客户端调用服务端方法

...

新建一个server，client启动报错，找不到这个包

可是我这里有啊

百度发现是以前踩过的坑

因为我的mapper.xml不再resource里面，maven默认是不编译的，需要做第五点

http://blog.csdn.net/ppppfly/article/details/46847299

这次报错，找不到了另一个类

这里也有啊

我猜测是mybatis-spring版本太高，下个12年左右的

这次服务端控制台输出东西，停不下来，jdbc连接失败

。。。原来是数据库没打开。数据出来了。卡了一天半！！

之前的server还是用不了。我想是因为jar包冲突了，一直报错没有合适的driver

然后是页面显示

客户端把端口号改一下

server没问题。首先，开启9989，关闭9988

不过9988的bean获取不到。在9988的xml里看是否有这个图标，如果没有，顶部有一个自动导入的

然后关闭9989，开启9988，刷新页面，没问题

我把server打包到linux发现运行不了。网上也没有相关资料。tuscany这个框架多年没更新， 就不在linux使用了

深度思考

什么是微服务：

https://www.cnblogs.com/hongxf1990/p/6491014.html

传统的系统架构是单一架构模式。这种架构模式就是把应用整体打包部署，具体的样式依赖本身应用采用的语言，如果采用java语言，自然你会打包成war包，部署在Tomcat或者Jetty这样的应用服务器上，如果你使用spring boot还可以打包成jar包部署。其他还有Rails和Node.js应用以目录层次的形式打包。

微服务架构则是将单个的整体应用程序分割成更小的项目关联的独立的服务。一个服务通常实现一组独立的特性或功能，包含自己的业务逻辑和适配器。各个微服务之间的关联通过暴露api来实现。这些独立的微服务不需要部署在同一个虚拟机，同一个系统和同一个应用服务器中。

二、为什么需要微服务架构？

单一架构模式在项目初期很小的时候开发方便，测试方便，部署方便，运行良好。可是当应用随着时间的推进，加入的功能越来越多，最终会变得巨大，一个项目中很有可能数百万行的代码，互相之间繁琐的jar包。

1、    不再适用敏捷开发，过于复杂，任何开发者都不能够完全理解，修复漏洞和实现新功能变得困难和耗时。

2、    规模越大，启动时间越长，自然会拖慢开发进度，一个小功能的修改部署起来变得困难，必须重新部署整个应用。

3、    系统的不同的模块的需要不同的特定的虚拟机环境时，由于是整体应用，那么只能折中选择。

4、    任意模块的漏洞或者错误都会影响这个应用，降低系统的可靠性

5、    还有一个如果想整体应用采用新的技术，新的框架或者语言，那是不可能的。

如果采用微服务架构模式，则可以解决单一架构模式带来的系统复杂性。主要包括以下几个好处：

1、    由于每个服务都是独立并且微小的，由单独的团队负责，仍然可以采用敏捷开发模式，自由的选择合适的技术，甚至可以重写老服务，当然都要遵守统一的API约定。

2、    每一个微服务都是独立部署的，可以进行快速迭代部署，根据各自服务需求选择合适的虚拟机和使用最匹配的服务资源要求的硬件。

3、    整体应用程序被分解成可管理的模块和服务，单个的服务可以更快的开发、更简单的理解和维护。

4、    一些需要进行负载均衡的服务可以部署在多个云虚拟机上，加入NGINX这样的负载均衡器在多个实例之间分发请求，这样不需要整个应用进行负载均衡了。

每个后端服务暴露一套REST API，大部分服务调用其他服务提供的API。每个服务都有自己的数据库模式，而不是共享单个数据库模式。尽管这会造成某些数据的冗余，但是对于微服务架构这个独立数据库模式是必要的，确保了独立服务之间的松散耦合。

以上介绍的微服务架构模式表面上类似于SOA，两种架构都包含一组服务。可以认为微服务架构是不包括Web服务规范（WS-）、企业服务总线（ESB）的SOA。基于微服务的应用倾向于使用更简单轻量级的协议，比如 REST 而不是 WS-。微服务自己实现类似 ESB 的功能并且拒绝 SOA 的其他部分，比如规范模式的概念。

禅道：http://task.ptteng.com/zentao/task-view-15916.html