开头语
各位同事们好，我叫侯坤林，非常感谢各位同事百忙之中抽出时间来听我汇报这两周的学习情况，我感到十分荣幸，我若有什么表达得不对的地方，还请各位同事多多包涵和指正，谢谢！
正文之前铺垫
我自己在学校，感觉自己学的勉强还行，天外有天，人外有人，来到公司后，我发现自己在学校学的东西，完全不全适应公司的需求，感觉自己又接触到新的东西。
不过，虽然我现在不太符合公司的要求，但我会积极努力的学习，努力跟上公司的脚步，争取不掉队，尽量快速的适应公司工作要求。
1. 敏捷开发
进公司的第二天，志亮给我一份学习计划。其中第一项就是敏捷开发。网上的敏捷开发信息很多也很全，说实话对我来说很难在短时间内理解和吸收。
下面是我根据网上的资料自己做的一些整理，当然肯定有很多错误的地方，或者不合理的地方，还望指出改正。
1.1 简单上线
在传统的项目开发中，从需求到开发到上线(需求整理、设计、开发、测试、部署上线)，会经历一个很长的阶段，在开发过程中有着完整的规范。敏捷开发的一点是，前期用简单的方法实现基础应有的功能，然后上线。在后期慢慢的完善功能。
1.2 快速迭代
在快速上线的同时，不免会出现使用问题，此时我们要定制一个迭代计划，每经过一段时间，修复一些问题并上线。有时候任务较多，可以适当的制作任务冲刺计划。
1.3 需求灵活
产品在上线的过程中，会不断的发现使用问题，以及用户需要的新功能。我们需要收集好问题和需求，然后整理出来，按照紧急程度排出计划任务，在迭代开发的时候优先处理优先级高的任务。
1.4 知识积累
项目的功能不断的变化，遇到的问题也是不同，在开发的过程中，遇到的不同问题并一一解决，每解决一个问题都会使我们积累一点知识，这样在开发的后期，我们的知识体系跟开发前完全不同，我们可以应用新的知识去完善项目刚开始开发的代码，以及把新的收获投入到下一个项目中。
1.5 团队沟通
敏捷开发由于在开发过程会遇到需求不断的变化，功能不断的完善，功能接口也会发生不同的变化，所以在开发的过程中，我们难以制定出一份完整、正常的开发文档，需要团队成员不断的沟通。但是功能完成后，开发文档和说明文档还是会及时的补全。
2. 容器技术
在微服务流行的这两年，docker容器也火起来，其以统一生产开发环境、易部署上线、方便集群为热点。docker分为三个点，镜像、容器、仓库。当然更深层次的我不太明白。
2.1 镜像
镜像是一个静态的东西，它是不会变动的，它含有一个系统的所有文件。容器镜像是分层结构的，通过挂载的方式来组合出一个系统所需的完整的文件系统。
2.2 容器
容器是动态的，当我们把一个镜像运行起来，就创建了一个容器，这个通过镜像正在运行的东西就叫做容器。跟操作系统的程序和进程很类似，一个程序是存储在磁盘的静态资源信息，当把这个程序运行起来，它就建了一个进程。镜像跟容器的关系，就跟程序跟进程的关系差不多。
2.3 仓库
仓库，存放东西的地方，用来存放镜像的地方，可以理解为就跟我们用的github差不多。把它存到仓库里面，可以让别人下载使用我们自己制作的镜像，或者在别人提供的镜像基础上再构建我们自己的镜像。
2.4 方便部署上线
通过镜像创建一个容器后，我们可以往里面安装软件和环境，把项目运行环境搭好后，可以把我们的程序放到容器里面，然后把这个容器重新打包成镜像。
当我们把这个镜像放到任何一台机器运行起来后，都能够运行我们的服务项目。这是因为这个镜像拥有着一个系统的完整文件系统，里面包含着一个系统的所有目录文件，包括我们安装的软件、环境以及我们放进去的部署项目。
通过这个镜像来创建一个容器，使其运行起来，由这个容器来提供服务。只要我们在本地调试好容器，制作镜像，不需要在服务器上重新安装各种运行的环境，只需要把镜像上传上去，通过镜像创建容器就可以运行项目，因此它是非常方便的部署项目上线的。
3. git flow
git flow 主要三种分支：master、develop、feature
- master 主分支，不应该在主分支上做开发
- develop 开发分支，当前正在开发的分支，汇集着当前已完成的功能，当开发分支开发完成测试通过后需要合并到主分支
- feature 功能分支，从开发分支分离出来的功能分支，当这个功能完成测试通过后需要合并到开发分支，并且删掉该功能分支
- release 预发布分支
- fixbug 修补BUG分支
git flow 主要是一种工作流程，把功能、任务独立出来建立一个分支，并且在这个分支上完成这个功能，之后再把完成的功能合并到开发分支上
4.1 微服务框架
主要说的是Java的微服务框架，其他语言肯定也有各自的微服务框架，但是我对这个并了解。
微服务包括以下几个部件：
4.1.1 服务治理
这个应该可以说是微服务框架的大脑、中枢，对外提供服务注册、服务发现等，所有的微服务都需要向它报备自己的信息。可以看做它手上有一本书，记录着所有在注册的微服务信息，比如包括IP地址和端口，以及它是否可用状态等。
4.1.2 路由网关
有了微服务提供服务，我们还需要对外提供一个统一对外服务的地址，那么这个就是路由网关，我们访问这个功能地址的时候，就由路由网关来决定到底具体访问哪一个微服务。并且还可以在路由网关这一层对用户的数据请求做一些处理。
4.1.3 熔断
微服务有时候有可能意外掉线，或者运行微服务的服务器出现异常导致微服务掉线，那么用户和其他的微服务就无法访问这个掉线的微服务，这时就需要在调用其他微服务错误的时候能够及时的处理错误情况，并且返回相关的错误信息，而不是置之不理。所以就需要有熔断，来处理调用其他微服务异常的情况。
4.2 微服务
微服务这一块，在这之前我仅仅只是稍微了解过一下而已，看过一点基础教程。这两周也是在网上查了微服务的相关文章，其中包括微服务的特点、架构等。同时也跑了一小部分网上搭建微服务的教程，然后用我理解的微服务思想来开发志亮给我安排的一个小任务-表单管理。
4.2.1 个人对微服务的理解
把一个应用拆分成若干个功能，把一个功能做成一个微服务，微服务之间互相独立，又可相互调用
4.2.2 功能单一
指的是一个微服务只提供一个功能。比如用户功能做成一个微服务，这个微服务就提供跟用户相关的功能，比如登录、注册、修改信息等。
4.2.3 独立开发、测试、部署、上线
由于每个微服务只提供一个功能，所以可以很方便的进行独立开发，独立测试，独立部署，以及上线。同时它是独立的，理论上可以采用不同的开发语言，但实际上我认为并不建议这么做，应当保持团队技术栈的一致性。这样团队协作开发的效率才会更高，互相之间的交流擦出的火花才会更多。
4.2.4 数据去中心化
前一条说了，微服务独立开发，那么每个微服务就可以有独立的数据库。那么也就可以不同的微服务采用不同的数据库技术。但这个问题跟前一条是一样的，我认为团队应该保持技术栈的一致性，在数据库方面也应当保持着一致性。
5. 代码功能任务：表单管理
在跑了一部分SpringCloud教程后，开始码代码了，在这个过程中我犯了非常低级并且很严重的错误。主要是一开始为了尽快的完成基础功能，使用MyBatis代码自动生成工具生成的接口没写注释，以及其他的接口和方法也没写注释，后来得一个一个的补回去。还有一些方法的命名不规范，后来逐个的改。
结束语
非常感谢公司能够给我这个实习的机会，感谢梁雄学长对我的指导和帮助。
还有感谢志亮在这两周给我做的学习计划，和在技术上给我的指导，非常感谢。
以后将有很长一段时间跟大家一起工作，希望能够跟大家成为朋友，如果以后工作中有什么做的不对的希望大家及时指出。
初来乍到，还有许多方方面面的知识需要向大家学习，还望在以后的工作中大家能够多多指教！
谢谢大家！
