由单体程序到微服务

很多的程序最开始都是单体程序, 在Java Web的世界里, 单体程序就是一个war,包含了需要包含的一切

• class
• 依赖jar
• 页面
• 配置文件 ...

这种程序挺好的, 在项目比较小的时候, 单体程序可以让我们很快地上线产品, 很快地迭代新功能. 直到有一天, 增加一个小功能, 都会牵出几个小虫子来, 再到最后, 这个单体程序的代码都没有人愿意去改了. 因为改她就意味着会引发问题, 还都是莫名其妙的问题.
一般在这个时候, 程序的代码行数基本都已经几千上万了, 或者更多.
出现这种问题, 就可以考虑改变一下架构, 比如--微服务.

微服务越来越流行, 最近三个月的面试过程中, 面试来的人都或多或说知道一点Spring Boot相关的东西, 虽然有人说Spring Boot就是微服务, 虽然有很多时候大家对微服务的概念并不是那么清晰.
但是, 毋庸置疑, 微服务, 确实慢慢火起来了. 那么究竟什么是微服务呢? 笔者从去年年中第一次接触到微服务概念, 再具体接触到Spring Boot, 再到Spring Cloud, 截止目前为止, 对微服务也有了一点自己的认识.
微服务重点在于"微"! 那么怎么样才算真正的达到了微服务的"微", 这个大家都有各自的说法. 那么到底怎么样才算是真正地达到了微服务呢?
笔者认为

微服务的实施是一个逐渐演进的过程, 在演进的过程中, 如果Scrum的每个Sprint一样, 根据具体的业务, 不断地拆分, 重构, 拆分, 重构... 经过多次重构, 不断让拆分出的服务更加合理, 架构更加清晰. 直到最后, 拆分出的服务之间的边界已经清晰, 且各个服务之间的逻辑相对独立, 能够独立维护, 部署, 且已经能很好地解决当前遇到的问题.
这个时候我们认为, 微服务的拆分已经基本ok.

微服务并不是越小越好, 在满足业务需求的基础上, 能做到独立部署, 运行, 就已经算是拆的比较好的微服务了.

上面提到了Scrum, 这个是敏捷开发的一种方式, 将一个完整的产品拆分成若干个迭代(Sprint)去完成. 通过每个迭代的测试, 回归. 不断地调整, 直到最后出来一个正确的产品. 是的, 不是成功, 是正确.

成功与否是市场决定的.

单体程序要改成微服务架构, 这个过程中也应该是一个不断调整的过程. 只有不断地调整. 最后我们拆出来的服务, 搭建的架构才会是正确的. 至于是不是一个成功的架构, 这个得看后面真正的线上运行到底怎样.只有实践才能检验.

这篇文章通篇都是理论, 现在的微服务基本都是从单体程序慢慢转过来的. 这是个好现象. 但是在这个过程中, 一定不能为了微服务而微服务. 满足业务, 满足我们初衷的微服务才是我们理想中的恋人.

合适才是王道.

微服务框架, 个人推荐Spring Cloud家族. 有兴趣的朋友可以持续关注笔者博客. 在这里也推荐两个博客给大家, 都是社区牛人, 希望对大家有用.

• 程序员DD|博客

• 周立|Spring Cloud

转载于:https://my.oschina.net/hanbin/blog/2875843