项目是一个典型的政务项目，信息化，用户都集中一个内网，且用户极其有限，涉及到一些系统集成，但总体的工作还是一些上报数据审批与流转等。
这个项目最终采用了微服务化的开发架构，这是极不合适的一个选择，当然是我认为的。
我其实能理解这么想的初衷，专人做专事（毕竟这个项目实在谈不上高并发）。什么意思呢，就是各个功能模块都由专人来开发，这样来保证开发效率和人员流动带来的一些附属问题。人类发展到今天，很大程度上是因为分工的细化，让不同的人专注到不同的点上，进而不断的推动这个领域持续精进。转到这个项目上，可以看到负责人员看到了这个点，但是为达到这个目的采取的方式，值得商榷。
软件发展到今天，一个重要的主题就是复用，这是软件人永恒的话题，在这里也是这样，其实就是想达到服务复用，进而简化开发，很好的想法，以下我谈谈自己的认识。
1. 代码复用：
这是最基础的，刚工作时就开始琢磨这个了。继承、模板模式、spring中的无状态bean等等，这些都在忙活啥，都是想一段代码，来做的事，不要分散到各个地方，就写在一个地方，别人来调用就行了。以上是深入到类内部的，我们再谈谈模块级别的。
在maven和gradle 这些玩意出现前，我们其实也能用ant之类的来做一下模块共享，但不够系统，也不够智能，更多的是靠程序员们通过脚本来自我控制。有了maven和gradle，我们可以直接通过工程依赖完成即写即编，一个模块改了，依赖它的模块立即就可以使用新特性，而不必打了新包放进去，这都得益于现在ide对maven和gradle的支持。另一方面，我们可以建自己的maven repo，将公司内部的公用模块，提交到这个私服上，其它的工程直接引用即可，给我们自己也留了一个版本管控的口，真好，:-)
以上是当前代码复用的使用情况，我们再来谈谈另一个层面。
2. 功能复用：
这个可能有些勉强，但我还是觉得有必要列上。在java这片，以spring boot为代码，挑起来服务复用的旗，为什么说是服务复用呢，因为它不光给你代码，还给你代码所依赖的jar，同时还给你做了默认的配置（而且一般的默认配置就能满足你的需要）。所以我们看到，这个层面的复用，是完全踩在代码复用的基础之上的，可能将其理解成 代码复用 + 自动配置，也感谢spring boot提供的这个小机制，其实去翻一下源码你就知道，boot仅是用了一个jar包内的文本文件记下自动配置的类的名字，然后利用反射来进行自动配置，多贴心啊，以后大家写的东西只要写上starter，别人也能用了。实现简单，但只要大家都遵守了，那么你写的功能就能惠及他人了，多好。
3. 服务复用：
大体可以将其理解成微服务，这个最典型，早期的SOA也是这事，就是你可以用我了，我通过一些中间件来将我的服务暴露给你。这个最灵活，还能弹性伸缩，让你从容面对各种情况。灵活的东西几乎必然失之于复杂，一旦复杂就需要人们通过运维来对其进行管理。原来的政务相关项目，一旦上线了，几乎不会有啥事，一旦有事了，没事，晚上重启一下呗，问题done。但是上了微服务后，一堆中间件，运维这个东西的人，要没几刷子，他还真不行。所以，如果不是要去面对一个需要弹性伸缩如高并发的场景，我真不觉得，选这个是对的。
必须要承认，互联网的出现，尤其是移动互联网，拯救了java的从业人员，十年前网站访问量有限，说实在的，当是时，我们都在想怎么用代码自动生成代码了，后来大数据的出现，高并发，微服务等等，让java可以成为一个终生从业的方向，所以感谢这个时代吧。以前好像linux c编程的，有点意思，现在我们java也能风起云涌了，多好啊。最近也在研究k8s的微服务框架搭建，要做一个项目，一起进步吧。。。。。。