2019年工作总结
在写这篇博客的时候，因为新冠肺炎疫情影响本人已经在湖北老家隔离一个多月了，当然这一个多月以来心中也是各种滋味，五味杂陈，生活中总是有太多的困难在考验着我们，但总归要去面对，并一步步去把困难踩在脚下，闲暇之余也是该对过去的2019年来做一个系统性的梳理工作了，只有不断去总结才能明得失，然后找到自己的不足，并在新的一年去努力探寻解决方案，最后才能不断取得进步，不辜负光阴，最终实现自己的人生价值。
还是和往常一样，主要是从纯技术上和生活中对过去的一年进行一个细致的总结，2019年是自己来上海的第五个年头，也是自己进行Asp.Net Core进行开发的第二年，这一年对技术和生活上上的理解有了更多的理解，经历过很多东西，感觉也是自己快速成长的阶段，说真的这一年真的也是非常辛苦，无论是业务设计团队、软件开发团队、BA、QA、运维......每一个团队都在为奇瑞的整个售后管理DMS软件系统贡献着自己的力量，从整个系统3家经销商试用，到后面增加到50家，再到最后100家......每一次成倍地增加经销商都是对整个系统并发性的一个巨大的挑战，每一个Sprint迭代都是对整个团队的巨大考验，因为越到后面每一次需求的变更都是对整个系统的一次巨大考验。最后一块报表的开发更考验对整个业务系统的熟练程度的掌控力，这里面遇到过很多的困难，好在整个团队克服了种种困难，最终都很好完成了这一切，整个过程中也面临着团队人员的离职，新成员的加入，整个项目团队管理人员的变更，这些都是对整个公司的一个巨大考验，最终留下来的都是对整个项目报有信心，并愿意为这个团队付出到最后的人，这些都是整个公司的巨大的财富，总之要对过去的2019年心怀感恩，是各种困难造就了我们......
技术上主要从一下这些方面来做一个总结：1 深入理解微服务架构， 2 Confluence.Kafka的使用，3 深入理解ABP框架，4 EFCore的使用，5 Git的使用，6 Docker的深入理解，7 HttpClient及Refit的使用，8 Grafana 监控程序的使用，9 CAP框架的研究......当然可以总结的东西实在是太多，很难在一篇博客中总结清楚，所以本篇结构只能够从大概上面去总结这些东西。
第一部分
1.1 深入理解微服务架构
这个是整个系统系统的核心，公司的第一代产品是单体架构，这其中遇到了各种问题，在微服务大潮的席卷之下微服务架构也成为了整个公司新产品架构的不二之选，根据公司对整个奇瑞售后业务的理解程度对整个业务系统进行微服务架构的拆分总体上分为主机厂业务和经销商业务，然后在这两块大的业务架构之下对业务进行更加细致的拆分，备件业务、服务业务、授权与权限、结算系统、报表......拆分之后每一个微服务对应独立的数据库，每个服务作为单独的镜像独立运行，当然这样整个系统增加了足够的灵活性但是也会造成各个微服务之间的沟通成本大增，同时各个数据库之间也会增加一些业务数据的冗余，同时也增加了问题排查的难度，这些都是整个微服务架构带来的深刻体验，当然任何一个业务架构肯定是利弊共存的，没有绝对完美的系统存在。
1.2 Confluence.Kafka的使用
既然上面提到系统中微服务架构之间的沟通，那么肯定少不了MQ,在我们的系统中采用了Kafka作为整个系统的MQ，各个微服务之间通过各种各样的消息进行业务之间的交互，当然除了使用MQ以外，使用HttpClient进行各种微服务之间的交互也是必不可少的部分，由于公司以前一直使用单体应用，所以对整个消息系统理解造成了一定的障碍，所以这个部分也是摸着石头过河，这其中也遇到过不少的困难，所以如何使用好消息队列对于整个系统的成败也是最关键的，因为丢失任何一条重要的消息对于整个系统来说都会产生非常严重的影响，这个部分可以看下之前写的博客，上篇和中篇。
1.3 深入理解ABP框架
这个在我们的系统中为了更好的组织项目代码，让整个代码更加符合领域驱动设计的思想，整个系统每个微服务代码都是用ABP框架作为默认的框架，这里面我们可以使用ABP框架自带的各种功能来避免重复造轮子，而且能够让整个代码更加紧凑合理，这个部分请参考之前的系列文章ABP框架概述。
1.4 EFCore的使用
EntityFramework Core是Asp.Net Core进行开发中最常用的ORM框架，使用ORM框架能够极大的简化代码的结构，提高开发人员的工作效率，更重要的是能够更加方便系统在不同的数据库之间进行切换，最大程度上提交代码的复用，我想作为任何后端开发人员对这个都不会陌生，在我们整个开发过程中从最开始的EFCore2.1版本到现在的EFCore3.1版本，由于框架还不是非常成熟，这其中也踩过不少坑，这个也同样通过一系列文章来进行描述，这里也不在赘述。
1.5 Git的使用
对于这个部分，其实最常用的也是那些基础性功能，拉取、推送、变基、合并......但是这一年的一大收获就是发现了一个非常好用的工具Fork，这个是完全开源的项目，你可以点击这里进行下载安装，官方网站里面有很多的说明，具体的使用技巧有待在具体的实践中一步步去理解,之前经常使用的工具GitKraken最新的版本也开始进行收费了，这个工具也可以去了解一下。
1.6 Docker的深入理解
这个部分也是后面需要进行加强的部分，说深入理解其实现在还是停留在使用常用的docker命令进行一些镜像的安装，由于我们现在的系统都是Docker上面跑的各种镜像文件，所以有必要去深入了解它，这个部分也是以后需要去加强的，因为这些东西现在还是停留在初步使用的基础上，后面随着对整个微服务的深入理解，相信也会有对Docker有更加深入的理解。
1.7 HttpClient及Refit的使用
关于这一块后面有单独的一篇文章会来详细介绍这个方面的内容，这里只是做一个概述性的总结分析，在我们的不同服务之间经常需要进行跨服务调用，由于很多时候我们需要去跨服务获取数据，这个时候通过HttpClient进行这种实时性的服务间调用就显得非常重要了，有了这个层次的理解，我们可以理解Refit是对HttpClient进行更深入一层的封装并加入了更多的特性从而来解决通过HttpClient访问的问题，同时通过Refit我们能简化大量的HttpClient的重复代码，让整个代码看起来更加整洁明了，当然封装之后我们会少了更多对技术细节的掌控，所以是否需要使用Refit这个库就取决于自己的需求啦，对于这块后面会有一个系列的文章来讲述。
1.8 Grafana 监控程序的使用
我们部署到生产环境的日志监控系统，现在主要是通过它来查看具体的日志信息，当然里面有很多的功能只不过是现在并没有使用到，现在对它的理解是生产环境的日志监控系统，能够帮我们快速监控系统中的错误，并快速找到具体的错误信息，从而解决实际问题。
1.9 CAP框架的研究
这一年就研究过ABP和CAP两个框架，而且都是由于项目的需要，研究CAP是因为现在项目中由于对Kafka的不熟练，之前在项目中出现过大量消息重发、Message TimeOut等一系列问题，从而让整个对整个项目产生了不必要的各种困扰，CAP的出现正是为了解决这些问题的，从而真正地保证整个不同微服务之间如何保持事务的一致性，当然现在对这个理解的也不太够，而且项目中也没有正式使用，期待在新的一年对这个开源项目有更多的理解，从而在项目中真正地实施落地。
第二部分
谈了那么多的纯粹技术上面的总结是时候谈一下自己这一年对自己的反思了，借此也谈一下自己的心路历程，想想自己做开发也整整5年了，一直都是.NET技术栈，从开始的WinForm到后面的WPF再到现在的Asp.Net Core Restful WebAPI开发，去年一年也是非常紧张的一年，由于奇瑞售后服务包括Exeed和奇瑞二期项目，整整一年都是在紧张的项目开发中度过了，从开始半个月一个Sprint一个迭代，到后面最紧张的时候一周一个迭代包括开发环境测试，用户测试再到后面上正式环境，一切都是非常紧张的进行开发，由于售后这一块和售前相比有更多的业务，同时调整的也是非常多的，基本上从7月份开始就是996这种频率了，几乎是将自己所有的时间都贡献给了工作，好在我还只有29岁扛一扛，熬一熬都没有任何问题，当然在整个过程中对框架和工具也有更多的认知，但是任何一个项目都是经历过不少的困难，既有技术上面的困难也有生活上面的困难，技术上面会面临对微服务架构的不熟练从而造成领域拆分上面的不清楚（一方面可能由于现有业务耦合度还是非常高的），这样就会造成整个项目代码中服务之间大量的HttpClient实时通讯互相调用，也有大量Kafka事件的发送和接收，这其中任何一环出问题（比如消息的丢失）都会造成很多意想不到的灾难性后果，这也是整个微服务架构所带来的挑战，当然这些都是技术上面带来的挑战。另外一大部分就是人员流动，这个也是不可避免的问题，由于项目的周期长强度高，所以时间一长就会造成很重的心里上面的压力，这个时候就会有很多人由于各种原因选择退出这个团队，而前面的人不断退出又会造成留下来的人心里对未来更加迷茫，找不到方向，特别是团队Leader的离开更加重了这方面的压力，这些都对自己产生了很大的困惑，后面又陆续有新人员的加入，所以和不同人员之间的磨合也是一种新的能力的培养，在人员进进出出的时候产生了一件比较大触动的事情，就是团队进来了一位大龄程序员，进来的时候大家都是带着学习的心态来的，因为之前对于他的理解仅仅是之前用了很多年的Asp.Net MVC和EF框架，按照我之前的认知切换到现在的工作应该是毫无压力，但是后面经过半个月的项目磨合发现有时候经验并不能和能力画上对等的，所以也给我们深深的上了一课你经验的积累到底有没有真正地提高你的能力，还是你工作的每一天就是在重复之前的工作，这要虚耗光阴只能让你被这个社会抛弃，到时候年龄一大你还怎么和年轻人去拼体力还怎么去保证高强度的项目进度的压力，这个也是我后面几个月反思的比较多的部分。
另外一部分就是自己比较困惑的部分，由于整个项目业务众多，每个人都做其中一个部分，所以缺乏对整个项目流程和业务有一个整体的认识而且由于我们和客户之间需求的沟通还是以公司业务人员为桥梁的前提下，这也是我比较困惑的地方，因为越到后面你就会发现你做的很多都是重复性的东西，技术上面的提升很有限，但是一直在这个行业你会积累到更多汽车行业方面的知识，其实这个也是一个相互矛盾的地方。第二个矛盾的地方就是项目的时间压力造成很多代码其实存在很多的效率和性能上面的缺陷，但迫于项目的时间压力总会放弃一些更好的实现方式（这样意味着你要花更多的时间去重构验证），也许这些都是从事业务开发人员心中永远的痛吧，这些矛盾想彻底解决应该非常难，以后能做的就是在这个之间找到最美好平衡方式吧。
2020年开局很艰难，但是期待自己用更好的状态来迎接生活的挑战吧，还是用自己最喜欢的那句话来激励自己吧：年岁有加并非垂老，理想丢弃方堕暮年......
