从零开始学架构 01-架构基础【笔记】

从零开始学架构(李运华) pdf下载地址
https://pan.baidu.com/s/1cZJOR3cfpmS1BDfp6gJaBQ
提取码:u2ou

说明:对从零开始学架构这本书看时所做的记录,对具体的功能点可以自行百度

  • 模块,逻辑角度拆分,如注册模块、登录模块
  • 组件,物理角度来分,如web服务器,nginx

框架是标准的,有规范的产品,关注规范

架构关注结构

软件架构指软件系统的顶层结构,为了高性能、高可用、可扩展、所以要做架构设计,但盲目的这样做会消耗很多额外的时间。

架构设计的目的是为了解决复杂度带来的问题

  • 单机复杂度
  • 集群复杂度
简单的系统更容易做到高性能,因为简单功能点越少,越好优化。
高可用指系统无中断地执行其功能,本质通过冗余来实现。加服务器,加机房,加厂家,如联通。
存储高可用的难点不在于如何备份数据,而在于如何减少或规避数据不一致,对业务造成的影响。
各种数据库出现解决的问题
  • nosql:为了解决关系型数据库,无法对应高并发访问带来的访问压力
    • mencache、redis只是把数据库的索引独立出来,做成了一个缓存系统
  • 全文检索引擎:为了解决关系型数据库,耐like搜索的低效的问题
    • solr+lucene
    • elasticsearch
  • hadoop:为了解决传统文件系统,无法对应海量数据存储和计算的问题
    • hadoop基础其实是集群方案+数据复制方案
架构设计原则
  • 合适原则,合适由于业界领先
  • 简单原则,简单优于复杂(结构复杂性,逻辑复杂性)
  • 演化原则,演化优于一步到位,类似于生物演化
为何备选方案
  1. 设计备选方案,备选阶段,关注的是技术选型,而不是技术细节,一般3-5个备选方案
  2. 评估和选择备选方案,备选方案,每个都是可行的,否则也不能叫备选方案
  3. 指导思想,最简单派,最牛派,最熟派,领导派
  • 横向扩展是web集群
  • 纵向扩展拆分为子系统
  • 从性能,复杂度,成本,可扩展,可用性进行对比,按优先级选择对比的属性
总结

首先分析出系统的复杂性,在挑选合适的架构模式进行组合

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值