作者 苏槐
自从 Martin Fowler 对微服务作出定义之后，微服务便火遍大江南北，网上出现很多文章来描述它的好处，也有很多文章来说明它的弊端。这便让很多小伙伴无所适从，微服务究竟是什么，要不要使用微服务架构，怎么实施微服务架构？我一直认为，微服务架构只是新瓶装老酒，这老酒就是模块化。如果在做系统设计时，已经把模块化做得很好，转型微服务只是顺理成章的事。如果模块化都做不好，转型微服务只会带来灾难。
2014 年底，我们团队意识到 Docker 技术可以帮我们大幅度提高软件产品的性能，降低硬件的投入，提高运维效率，便开始着手研发基于 Docker 的 PaaS 平台。随后，很快发现，PaaS 平台只是解决了软件生命周期后半部分（运维）的问题，就思考能否通过 Docker 技术来提高开发团队的效率。例如，降低团队成员流动带来的风险，提高多团队协作的效率，找到组件或知识积累的方法，让同一个软件产品能够适应不同客户的定制化需求，等等。从此，就与微服务结下了不解之缘。这些目标确定后，通用的 PaaS 平台的研发目标也就变成了解决以上问题的微服务平台的研发，以及后来的青柳云平台本身的微服务化的实践。
在做微服务架构技术选型的时候，我们以“无侵入”和“社区活跃”为最主要的考量点，也只有这样，将来在升级为原子服务架构、量子服务架构的时候，甚至是恢复成单体架构的时候，代价才是最小的。所以，在为数不多的可选项中，我们拥抱了 Spring Cloud。最后的结果就是使用基于 Docker 的微服务平台进行开发和运行运维支撑，使用 Spring Cloud 进行业务系统开发，两者相互独立，并可被独立替换。
所以，本系列文章就是将以上过程给大家做个分享，不深究概念，不深入细节，只希望能够对微服务架构能够有一个相对全面的认识，从而能够帮助大家成功落地微服务架构。
目录
（一）《重识微服务架构》
（二）《快速体验微服务架构》
（三）《微服务架构 API 的开发与治理》
（四）《如何保障微服务架构下的数据一致性》
（五）《代码给你，看如何用 Docker 支撑微服务》
评论