BT

你的观点很重要! 快来参与InfoQ调研吧!

Re:从 0 开始的微服务架构

| 作者 苏槐 关注 31 他的粉丝 发布于 2017年11月3日 ArchSummit社交架构图谱:Facebook、Snapchat、Tumblr等背后的核心技术

目录

(一)《重识微服务架构》

(二)《快速体验微服务架构》

(三)《微服务架构 API 的开发与治理》

(四)《如何保障微服务架构下的数据一致性》 

(五)《代码给你,看如何用Docker支撑微服务》
 

卷首语

作者 苏槐

自从Martin Fowler对微服务作出定义之后,微服务便火遍大江南北,网上出现很多文章来描述它的好处,也有很多文章来说明它的弊端。这便让很多小伙伴无所适从,微服务究竟是什么,要不要使用微服务架构,怎么实施微服务架构?我一直认为,微服务架构只是新瓶装老酒,这老酒就是模块化。如果在做系统设计时,已经把模块化做得很好,转型微服务只是顺理成章的事。如果模块化都做不好,转型微服务只会带来灾难。

2014年底,我们团队意识到Docker技术可以帮我们大幅度提高软件产品的性能,降低硬件的投入,提高运维效率,便开始着手研发基于Docker的PaaS平台。随后,很快发现,PaaS平台只是解决了软件生命周期后半部分(运维)的问题,就思考能否通过Docker技术来提高开发团队的效率。例如,降低团队成员流动带来的风险,提高多团队协作的效率,找到组件或知识积累的方法,让同一个软件产品能够适应不同客户的定制化需求,等等。从此,就与微服务结下了不解之缘。这些目标确定后,通用的PaaS平台的研发目标也就变成了解决以上问题的微服务平台的研发,以及后来的青柳云平台本身的微服务化的实践。

在做微服务架构技术选型的时候,我们以“无侵入”和“社区活跃”为最主要的考量点,也只有这样,将来在升级为原子服务架构、量子服务架构的时候,甚至是恢复成单体架构的时候,代价才是最小的。所以,在为数不多的可选项中,我们拥抱了Spring Cloud。最后的结果就是使用基于Docker的微服务平台进行开发和运行运维支撑,使用Spring Cloud进行业务系统开发,两者相互独立,并可被独立替换。

所以,本系列文章就是将以上过程给大家做个分享,不深究概念,不深入细节,只希望能够对微服务架构能够有一个相对全面的认识,从而能够帮助大家成功落地微服务架构。

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT