[Day - 30] - Spring framework research conclusions

Conclusions and Discussion

在这二十几天来的技术文章分享，我们可以看到每个开发功能面的架构与流程，我们从最基层注解模式讲到最上层的注解模式，都是顾虑到一个重点：共用性，身为开发者的你，无论多大多小都要保留弹性，让未来相关功能可以一起共用，在抽象出许多种不同的模式运用，区分其应用领域，如同注册功能而言，无论何种元件，追究至底层，都只是一个Bean元件，只是区分很多种不同领域模式的注解，并加强他的额外功能，一个系统的强大不在於它的技术有多新潮，有多漂亮的架构，只有在你的“齿轮”设计颗粒度有多漂亮，一样的道理，Spring 注解式架构是多麽的新潮、多麽的炫，追究至底层，他还是用既有的BeanFactory元件进行获取Bean元件，新只是一种方式，技术依旧，小编还是维持那句话：『没有新旧技术，只有你不知道的好用技术，就是新技术』，分享这麽多天技术底层架构，小编也追逐很多样式的前後端新技术，最後还是选择回到最原有的底层架构，因为它终究是最重要的基底，所以，从这边可以看出，很多还是沿用原有的框架，不用无谓汰旧换新，那只会让你的宝贵资料模型无谓牺牲，如何让既有的技术框架保有原有思想，并持续重构的迎接新的技术思想，才是重要的未来课题。这也是小编为什麽要拿Spring框架来当成功的技术案例分享。无论在於结构、效能、测试、微服务及监测等，都具备各种优势，可从此分析是一项非常稳定的框架，虽然在某些元件齿轮的技术上，尚有不足与重工，如同　Reactor虽好，但依旧在重构，效能面依旧存在议题，新旧版本不相容，以下相关结论提供给各位开发者作参考。

Implementation

最後各位可看到完成後的系统服务架构(图一)如下，我们并整合Spring 各式注解模式、Swagger API范例及Spring Reactor功能，并在整合Spring Actuator 套件终端点接口，开发了一套服务服务监测服务，进行监测服务运作的过程与异常。

图一、产品系统结构

透过图二我们可看出，监测支援非常全面化，可支援客制化终端点、记忆体资讯监测、Bean资讯监测、系统健康资讯监测、系统环境配置及排程资讯等等，可提供给开发者快速透过此监测服务的相关资讯进行障碍排除，资讯可以比JConsole更佳完整。

图二、修改後服务系统监测介面

图三、传统介面监测画面

以上为这三十天来的技术分享实作内容，分享给大家做参考，若有相关问题可在与我联系喔，但我小编很忙，会很晚才回，谢谢。

Future plans

未来在後端的开发规划，小编评估Spring将朝向效能优化及完整的Lambda开发模式编程，在整合透过新式的垃圾回收(Garbage Collection，GC)机制提升其效率，毕竟现在整合套件多样化，但如何有效的控管各套件执行绪效率是另外一个值得探讨的议题，在於设计模式方面相对应整合功能多，但部分旧技术已出现不相容的情况，导致各个Repository越切越细是值得深思的议题，这样只会变得相容度越来越低，这也是小编为什麽透过其他Script整合部分套件功能原因。

Acknowledgment

感谢我妈生了我，让我依旧无聊的发呆活着，感谢我的指导教授，让我知道在研究室就是要待到半夜，这样在业界就习惯了～非常好！这是真的！谢谢郑教授～谢谢，感谢第一间公司的架构师，他点醒了我，我开寻找新未来，太棒了～我觉得人生充满了希望！谢谢大家！

就是现在！Rignt now！Currently！！At present！！！我已经不是小编拉！！！！！我是真新镇的威斯丁，梦想是成为无聊程序训练大师，让我们开始我们成为程序训练大师之路努力吧！谢谢大家 掰掰

Darius Weisting.