本来计划写作不是日更的，但是既然能有时间来写，那就坚持日更吧。加油！
序
早上坐车的时候，突然进入了对这短时间学习的总结性思考。随后记录下来以供后续复盘。
梳理
架构本质
关于什么是架构，以及架构的最根本目的是什么，有很多不一样的说法。最近在学习架构课程，暂且对里面的定义还是比较认可的。
什么是架构
比较常见的一种说法是：架构是对业务场景抽象出来的支撑骨架。我再延申一点，架构是支撑以及连接业务的骨架。
但是，单从业务场景来说有比较狭义，再继续延申的话，那就是对场景的抽象，场景包括但不限于：业务、人力成本、时间成本、硬件成本、能力水平等等。
架构的目的
关于架构的目的，我想从两方面来阐述想法，一是企业的角度，二是用户的角度。
-
站在企业的角度，架构的目标应该是：降本增效。在控制成本的前提下通过优雅的架构来提升企业的效率。
-
站在用户的角度，架构的目标应该是：7*24小时可用，再明确点来定义可用性的话，就是用户无论在什么时间、什么地点、使用任何可达网络服务都能在可接受的时间内返回正确的值。
架构的三个原则
引用架构课程中的三个原则：合适原则、简单原则、演化原则。一个架构要时刻都满足上述三个原则，对架构师的考验是巨大的，考验的就是架构师的折中能力。
关于合适、简单原则更多的是需要基于实际场景来设计的。而演化原则，在目前已经有了一定的相对而已比较普适的手段：拆。
纵观互联网架构的演进历程，最本质的手段是对已有系统实施拆字诀。
- 从单体架构-->面向服务架构：对单体应用实施垂直拆分。
- 从单体架构-->水平分层架构：对单体应用实时水平拆分。
- 从面向服务架构/水平分层架构-->微服务架构：对面向服务架构再实施水平拆分，或者
- 对水平分层架构实施垂直拆分。
- 从微服务架构-->服务网格价格：对微服务架构实施业务设计与业务通信拆分。也就是将与业务无关的基础设施组件拆出来，下沉到微服务下面。
至于中台架构，应该更多的是在微服务架构上，进行了公用功能的合并。至于什么是中台架构，如何来实施，以后再专题研究。所以架构纵观起来可能也不是那么的难，重点是掌握本质的东西。
关于架构下一步的思考
从实施拆字诀后，系统的可用性有了极大的提升，但是因为服务分布式部署而引起的数据不一致性，给我们的架构带来了巨大的挑战。
关于一致性的挑战和解决方案，我们就放到明天来梳理吧。
网友评论