《从0开始学架构》的收获
- 作者是阿里的技术资深专家，文章内容简单朴实，但真的是0基础来学的话，个人感觉理解起来还是有点吃力的。
- 作者的专栏主要分为了5个部分：基础架构、高性能架构模式、高可用架构模式、可扩展架构模式、架构实战。
- 基础架构部分，我认为是精华，很多资料网上根本没法找，比如设计架构的三原则、架构设计的流程和方案。架构实质就是解决各种复杂度问题，那么复杂度的来源，主要是哪些呢？其实主要是出自业务的需求，比如高性能、高可用、可扩展。试想要解决好这些问题，架构师的功力要有多深厚。
- 在进行设计架构时，一般遵循三个原则：“合适原则”、“简单原则”、“演化原则”。
- 合适原则：没有最牛逼的架构，只有最适合业务的架构。
- 简单原则：理论上架构越简单，后面越容易维护和扩展。
- 演化原则：架构设计本身是一个随着业务发展，需要不断迭代的工程，没有一劳永逸的架构。
- 谈到高性能，有数据库机器的读写分离、分库分表，缓存架构。有单服务器的
PPC(Process Per Connection)、TPC(Thread Per Connection)、Reactor、Proactor高性能模式。有高性能的负载均衡和算法。 - 谈到高可用，你需要知道
CAP理论，因为分布式系统一定存在P(比如网络分区的存在导致数据非强一致性而是最终一致性)，所以理论上只能做到CP或AP。在设计高可用架构时，为了避免思考不全面，应采用FMEA方法，即Failure mode and effects analysis（故障模式与影响分析），又称为失效模式与后果分析、失效模式与效应分析、故障模式与后果分析。相比计算型高可用，存储型高可用相对复杂。存储型高可用我们一般采用双机架构(主备、主从、主备 / 主从切换和主主)，集群和分区，分区又涉及异地多活。而面对业务级别的接口故障，要有降级、限流、熔断、排队等手段。 - 谈到可扩展，核心就是“拆”，面向流程拆分就是分层架构，面向服务拆分就有SOA和微服务，面向功能拆分就有微内核架构(插件化架构)。
- 学会上面这些，就很牛逼了？肯定不是，到后面你会发现，软技能也很重要。每个架构由于每个人理解的不同和业务背景的不同，就会产生许多的说法甚至是争论。面对这样场景，作为架构师，你应该拿出数据和业界理论说话。同时言辞也不应太激烈，尽量让你的合作伙伴能欣然接受。有时架构师会提出架构重构的需求，这时架构师不仅要保证当前业务的发布进度，还得承担架构重构或者变动带来的风险，最后还得说服项目经理。
- 最后，既没有最好的架构，也没有一劳永逸的架构。架构师的牛逼之处就在于可以在成本和业务稳定性之间找到一个最佳的平衡点，让架构产生的价值对业务最大化。
赏
支付宝打赏
微信打赏
支付宝打赏
微信打赏
赞赏一下
