2019.9.9到9.10，花了两天的时间通读了《从零开始学架构》。
在互联网的浪潮下，技术迭代如此之快，不免心生疑惑，有些迷茫。
大三下学完spring+springmvc以及mybatis的组合框架以为终于能歇一歇了，springboot和springcloud映入眼帘。了解完springcloud组件后对单体和微服务之间产生了极强的主观偏见，分布式，集群，高性能，高可用这些名词在大脑中留下了深深的烙印。
大四想跟朋友一起开发一个app，却在后端技术选型上面犯了难。刚刚学完springcloud的我自然是想用以至用。但理智让我冷静了下来，微服务真的适合我们吗？
且不说业务开发的难度，docker和k8s的部署我只是有所耳闻，根本不能信手拈来，团队里的其他人也没有了解过容器化部署的相关技术。
9.8晚由于白天的焦灼和问题难以解决，晚上10点就早早入睡了。第二天起了个大早，突发奇想去图书馆溜达溜达，暑假过去两个多月，图书馆四楼最靠窗的新书架又更新了。挑几本感兴趣的，于是两天的疯狂阅读开始了。
如果拿三国鼎立时代来做比喻的话，书里没有描绘子龙是如何习武，军队是如何训练，而是讲述孔明是如何行军布阵，运筹帷幄的。
在书里几乎没有一行关于代码的阐述，而是着眼于整个系统的结构和设计，或者说是一种立足与软件开发上的全局观。
合适，简单，演化三个原则瞬间解决了我的困惑，聚焦于技术，就会为了使用技术而使用技术。
针对具体的业务和预算成本制定合适的开发计划才是可取之道。
数据库的选择和缓存的使用，搭建服务器集群实现存储和计算的高可用，高性能。
随着业务的发展，初期的架构产生瓶颈。需要更高性能的服务提供。与此同时，会带来成本上的剧增。所以在项目开始，对于初创项目，并不建议直接采用这种方式，当业务访问量过小，高性能，高可用就是一场打水漂的游戏，白白浪费了资源。
分层，soa和微服务。同样，分层结构对比之下最为简单，而soa是针对于大量异构的it系统的整合，微服务是业务发展后理想的样子，但服务粒度划分值得商榷。
开篇淘宝的发展史令我为之震动。
其中，
互联网业务发展
非常具有参考价值，是在技术选择盲目时的指南针。
技术是随着业务发展而变化的，合适优于业界领先，简单优于复杂，演化优于一步到位。
如对本文有疑问， 点击进行留言回复！！
我要评论
网友评论