2019.9.9到9.10,花了两天的时间通读了《从零开始学架构》。


在互联网的浪潮下,技术迭代如此之快,不免心生疑惑,有些迷茫。

大三下学完Spring+SpringMVC以及MyBatis的组合框架以为终于能歇一歇了,SpringBoot和SpringCloud映入眼帘。了解完SpringCloud组件后对单体和微服务之间产生了极强的主观偏见,分布式,集群,高性能,高可用这些名词在大脑中留下了深深的烙印。

大四想跟朋友一起开发一个APP,却在后端技术选型上面犯了难。刚刚学完SpringCloud的我自然是想用以至用。但理智让我冷静了下来,微服务真的适合我们吗?

且不说业务开发的难度,Docker和K8s的部署我只是有所耳闻,根本不能信手拈来,团队里的其他人也没有了解过容器化部署的相关技术。


9.8晚由于白天的焦灼和问题难以解决,晚上10点就早早入睡了。第二天起了个大早,突发奇想去图书馆溜达溜达,暑假过去两个多月,图书馆四楼最靠窗的新书架又更新了。挑几本感兴趣的,于是两天的疯狂阅读开始了。


回顾一下

如果拿三国鼎立时代来做比喻的话,书里没有描绘子龙是如何习武,军队是如何训练,而是讲述孔明是如何行军布阵,运筹帷幄的。

在书里几乎没有一行关于代码的阐述,而是着眼于整个系统的结构和设计,或者说是一种立足与软件开发上的全局观。

第一部分 架构设计原则和流程

合适,简单,演化三个原则瞬间解决了我的困惑,聚焦于技术,就会为了使用技术而使用技术。
针对具体的业务和预算成本制定合适的开发计划才是可取之道。

第二部分 高性能,高可用架构模式

数据库的选择和缓存的使用,搭建服务器集群实现存储和计算的高可用,高性能。

随着业务的发展,初期的架构产生瓶颈。需要更高性能的服务提供。与此同时,会带来成本上的剧增。所以在项目开始,对于初创项目,并不建议直接采用这种方式,当业务访问量过小,高性能,高可用就是一场打水漂的游戏,白白浪费了资源。

第三部分 可扩展架构模式

分层,SOA和微服务。同样,分层结构对比之下最为简单,而SOA是针对于大量异构的IT系统的整合,微服务是业务发展后理想的样子,但服务粒度划分值得商榷。

第四部分 架构实战

开篇淘宝的发展史令我为之震动。

其中,
互联网业务发展

  • 业务复杂性
    • 初创期(创新,快)0-1w
    • 发展期(堆功能,优化期)1w-10w
    • 架构期(拆功能,拆数据库,拆服务器)10w到100w
    • 竞争期(平台化,避免重复造轮子;服务化,解决系统交互问题)1000w+
    • 成熟期(优化)1亿+
  • 用户规模增大
    • 性能
    • 可用性

非常具有参考价值,是在技术选择盲目时的指南针。


小结:

技术是随着业务发展而变化的合适优于业界领先,简单优于复杂,演化优于一步到位。

版权声明:本文为noneplus原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/noneplus/p/11497058.html