码农小光 的文章的记录
单机架构
第一次演进：Tomcat与数据库分开部署
第二次演进：引入本地缓存和分布式缓存
第三次演进：引入反向代理实现负载均衡
第四次演进：数据库读写分离
第五次演进：数据库按业务分库
第六次演进：把大表拆分为小表
第七次演进：使用LVS或F5来使多个Nginx负载均衡
第八次演进：通过DNS轮询实现机房间的负载均衡
第九次演进：引入NoSQL数据库和搜索引擎等技术
第十次演进：大应用拆分为小应用
第十一次演进：复用的功能抽离成微服务
第十二次演进：引入企业服务总线ESB屏蔽服务接口的访问差异
第十三次演进：引入容器化技术实现运行环境隔离与动态服务管理
第十四次演进：以云平台承载系统
总结:
-
IaaS：基础设施即服务。对应于上面所说的机器资源统一为资源整体，可动态申请硬件资源的层面；
-
PaaS：平台即服务。对应于上面所说的提供常用的技术组件方便系统的开发和维护；
-
SaaS：软件即服务。对应于上面所说的提供开发好的应用或服务，按功能或性能要求付费。
至此：以上所提到的从高并发访问问题，到服务的架构和系统实施的层面都有了各自的解决方案。但同时也应该意识到，在上面的介绍中，其实是有意忽略了诸如跨机房数据同步、分布式事务实现等等的实际问题，这些问题以后有机会再拿出来单独讨论。
4、架构设计总结
1）架构的调整是否必须按照上述演变路径进行？不是的，以上所说的架构演变顺序只是针对某个侧面进行单独的改进在实际场景中，可能同一时间会有几个问题需要解决，或者可能先达到瓶颈的是另外的方面，这时候就应该按照实际问题实际解决。如在政府类的并发量可能不大，但业务可能很丰富的场景，高并发就不是重点解决的问题，此时优先需要的可能会是丰富需求的解决方案。2）对于将要实施的系统，架构应该设计到什么程度？对于单次实施并且性能指标明确的系统，架构设计到能够支持系统的性能指标要求就足够了，但要留有扩展架构的接口以便不备之需。对于不断发展的系统，如电商平台，应设计到能满足下一阶段用户量和性能指标要求的程度，并根据业务的增长不断的迭代升级架构，以支持更高的并发和更丰富的业务。3）服务端架构和大数据架构有什么区别？所谓的“大数据”其实是海量数据采集清洗转换、数据存储、数据分析、数据服务等场景解决方案的一个统称，在每一个场景都包含了多种可选的技术如数据采集有Flume、Sqoop、Kettle等，数据存储有分布式文件系统HDFS、FastDFS，NoSQL数据库HBase、MongoDB等，数据分析有Spark技术栈、机器学习算法等。总的来说大数据架构就是根据业务的需求，整合各种大数据组件组合而成的架构，一般会提供分布式存储、分布式计算、多维分析、数据仓库、机器学习算法等能力。而服务端架构更多指的是应用组织层面的架构，底层能力往往是由大数据架构来提供。4）有没有一些架构设计的原则？
-
N+1设计：系统中的每个组件都应做到没有单点故障；
-
回滚设计：确保系统可以向前兼容，在系统升级时应能有办法回滚版本；
-
禁用设计：应该提供控制具体功能是否可用的配置，在系统出现故障时能够快速下线功能；
-
监控设计：在设计阶段就要考虑监控的手段；
-
多活数据中心设计：若系统需要极高的高可用，应考虑在多地实施数据中心进行多活，至少在一个机房断电的情况下系统依然可用；
-
采用成熟的技术：刚开发的或开源的技术往往存在很多隐藏的bug，出了问题没有商业支持可能会是一个灾难；
-
资源隔离设计：应避免单一业务占用全部资源；
-
架构应能水平扩展：系统只有做到能水平扩展，才能有效避免瓶颈问题；
-
非核心则购买：非核心功能若需要占用大量的研发资源才能解决，则考虑购买成熟的产品；
-
使用商用硬件：商用硬件能有效降低硬件故障的机率；
-
快速迭代：系统应该快速开发小功能模块，尽快上线进行验证，早日发现问题大大降低系统交付的风险；
-
无状态设计：服务接口应该做成无状态的，当前接口的访问不依赖于接口上次访问的状态。
作者：码农小光
链接：https://www.jianshu.com/p/9f985bbc9c70
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
来源：CSDN
作者：thefzym
链接：https://blog.csdn.net/thefzym/article/details/104481713