微服务架构实践之邮件通知系统改造
拆分背景
随着平台业务增长，功能耦合度越来越高，部署周期变长，代码样式混乱、新人入手复杂、独立功能影响系统的稳定性等等，等等，等等问题。
以邮件通知为案例对服务进行拆分，独立服务，独立部署，独立进程，做到及时上线而不影响平台正常运营。
以此为例，望大家对于经手的功能模块，有一个良好的规划，不要碍于项目进度而给自己或者别人制造麻烦。
拆分原因
-
邮件通知分散于各个系统，配置变更容易遗漏
-
代码分散，功能修复麻烦，相应的增加部署难度
-
多人经手，代码风格不同，不易于维护
-
发送模版不规范，导致发送风格迥异
-
线上生产环境出现问题，在不影响正常运行的情况下，不易于修复
-
功能集成在项目，增加了调试的难度
-
影响平台稳定性
拆分优势
系统拆分虽然会增加了复杂性，但是可以得到更多的好处
-
数据闭环实现自我管，不依赖于任何系统，即去依赖化这样的好处是别人抖动不会影响到自己
-
数据异构，即将各个系统的数据传输过来，按照自己的要求去处理
-
基于Maven管理项目，相比于项目中的Ant构建更高级，当然功能不仅仅是构建，还有一些列的优势
-
SpringMvc+Dubbo实现服务治理，对外开放接口，也可以自定义实现HTTP请求
-
基于Thymeleaf模版，实现邮件动态内容模板话，良好的封装，便于开发和查阅
-
初次采用Log4j2 ，睁大眼睛是二，没错，对比log4j和logbak性能大幅度提升
-
独立服务，独立部署，独立进程，更加灵活易部署，易扩展
-
使用LinkedBlockingQueue安全队列做任务队列(咱不考虑)
-
额外增加Redis是为了在大量邮件发送请求下缓解邮件发送服务器压力(咱不考虑)
技术实现
Maven、SpringMvc、Dubbo、redis、Thymeleaf、Log4j2、MQ
技术问题
如何快速入门Maven
如何轻松搭建一个Maven项目框架
对于在Maven库中不存在的Jar该如何处理
如何搭建SpringMvc基础配置
关于Log4j2的正确使用
模版Thymeleaf如何生成静态文件
任务队列LinkedBlockingQueue实现
redis使用场景
MQ使用场景
架构图例
关于Maven
关于流程
小站：https://blog.52itstyle.com/archives/1012/
