《从0开始学架构》——学习笔记(基础篇、高性能篇、高可用篇和可扩展篇)...

       继去年写完"《从0开始学架构》——学习笔记(基础篇和高性能篇)"之后,一直忙于项目的开发中,无暇顾及后面的篇章。最近一段时间,忙碌的项目工作已经接近尾声,突然想起来,之前与大家约好的《从0开始学架构》学习笔记的高可用和可扩展篇还未写,于是,这几天整理了一下,把最新的成果给大家分享一下。

       请尊重作者劳动成果,转载请标明原文链接:

  https://www.cnblogs.com/jpcflyer/p/9194679.html

       首先,还是让我们用一张图把精华总结一下吧

 

       然后简单的总结一下:架构设计的核心就是围绕高性能、高可用和可扩展等方面,针对不同的设计复杂度和关键点,进行架构方案的设计和取舍。图中对各方面的基本概念、场景分类和不同架构的优缺点进行了总结,总结的非常全面。大家在看图的时候,一定要结合自己在实际工作的场景分析,哪些场景是否用了各自场景的架构方案,如果没有,那是为什么?

       《从0开始学构架》整体来说面向的是无架构基础的开发人员,概念丰富,而且通俗易懂。但对于经验丰富的开发人员,则本篇的知识还不够深入。后面准备继续深入阅读李智慧的《大型网站技术架构-核心原理与案例分析》,从更深入全面的角度对架构进行分析,让更多的读者能够与我一起学习到架构的乐趣,敬请期待吧。

       搜索关注微信公众号“程序员姜小白”,获取更新精彩内容哦。

转载于:https://www.cnblogs.com/jpcflyer/p/10645872.html

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

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值