近期，在培训分享的时候，有幸再次得知springboot这个微服务框架。对于微服务这个框架本身，没有太大的兴趣，但对于它的发展倒是来了精神，因此，本篇博客，继续发扬东拉西扯的鬼吹胡扯精神，说说自己对于这个微服务的理解（PS：对于springboot，折腾了好久，也没有弄出来一个小demo，卡在依赖父工程spring-boot-starter-parent，无法解析父工程pom，然后换了另外一种方式，通过import的方式添加父工程依赖，也没起作用，暂时不管了，先放着，有已经弄好的朋友，可以考虑可怜可怜我，给我来个demon，将不甚感激）
一、形象概述
首先，先借来一个总结：
“Design is there to enable you to keep changing the software easily in the long term” —— Kent Beck
再借来一个时序图：
二、个人问题
1，那天分享的时候，我就在想，这个微服务，和单一应用是啥关系？还有整出来这么个东西，是不是忘了当年学软件工程的时候，有个模块化思想？还有啊，有没有想起来算法里面的分而治之？整个springboot，虽然从表面上看来确实添加的依赖减少了，可是，我才不信springboot的那个聚合父工程没有当年让我眼花缭乱的依赖，哼！ 当年读了好几个版本的软件工程，现在看来，领悟的还是不够啊！ 其次，个人的知识网编的也忒烂了点，竟然没有联系起来具体的东西！
2，我在整那个springboot的时候，我个人觉得是整了个笑话出来，为什么呢？请允许我说说我这个心理过程：
首先，我是想要搭个聚合工程，然后，在这里面添加springboot的依赖引用（也就是文档里面说的用dependencymanagement的import形式，因为没法儿整两个pom父工程文件嘛，虽然没有成功）
其次，我想等我整好那个父工程后，开始搭建我的service、web、pojo、Dal这些服务，然后使用传递依赖，让子项目使用父工程的依赖项（先不说这个传递依赖的问题，暂时我是这么想的）
然后，我突然想到一个问题：为啥我没看出来这个“微”的意思呢？难道整出个springboot，就是为了让我少写几个依赖的？
最后，我不得不承认，我对这个springboot也好，微服务也好的理解，真心偏移了正确的轨道！
附录：微服务的优点
每个服务都很简单，只关注于一个业务功能。
每个微服务可以由不同的团队独立开发。
微服务是松散耦合的。
微服务可以通过不同的编程语言与工具进行开发。
三、图解程序的演变
我最开始接触合作的系统是一个机房收费系统，我那时候还整出个笑话，就是三人合作，我给整了三个解决方案，我想着最后把三个解决方案拼一起不就可以了吗？后来，我问了问前辈，他们说我这样不行！然后，基于画图和写文档的辛酸，我就想过，要不然自己整自己那个模块的文档和代码，避免svn冲突，也自己整个解决方案好了，最后再进行拼合！ 唉，这些都是前奏，后来，我走了和大家同样的路！
但是，就我个人来说，我认为，这个微服务的根源还是要追溯到我对于模块化开发的理解！从模块化开始，系统开始分解了，一旦一个问题开始进行分解，就跟那个二分查找似的，效率就提上来了，问题也就变得简单了！
模块化：将系统分解成若干个模块，每个模块实现特定的功能，最终的系统由这些模块组装而成，模块之间通过接口传递信息。
从模块化的定义，再联系到微服务，其实，真的很像呢？（主要思想）
结构化以后，有了面向对象的思想等等一系列的演变，但从深了看，也不过是对于系统继续进行抽象分离，进行模块组件的拆分（那个领域驱动设计，同样也跑不掉这个模块化的思溪那个）包括集群和分布式，也都是基于“拆”！但是，微服务，真的好吗？个人感觉，微服务虽然是为了简化程序而作的拆分细化，但是，如果一个系统庞大，被拆成了很多微服务，这中间的通信、安全问题等，同样也是赤裸裸的成本和挑战啊！适可而止。。。。。。
好吧，基于我这个对于模块化，深度喜爱的人来说，我感觉这个程序设计开发，转了一圈，又给我回去了！
四、感受
微服务这个概念出来后，势必会在管理上和通信上造成一定的挑战！不停的开发部署什么的，就会涉及到环境配置，这时候统一打包封装docker好像就有那么点意思了！那个什么服务注册dubbo也有那么点意思了！单点登录的cas，也更有意思了！把东西一拆分，好像突然间什么都变得有意思了，虽然我仍然都不会！
接下来的计划，是看看书，具体看看这个传说中的微服务框架springboot是个什么情况！目前来说，要我说，这个玩意儿，就是把那个spring的服务再次进行了封装打包，让开发程序变得快速简单了点而已！微服务嘛，重要的不是这个框架呀呀呀呀呀呀呀！
最近一直在整微积分啥的，请原谅我这么篇博客！！！惭愧中。。。。。