一.优化的哲学 1.优化可能带来的问题? 优化不总是对一个单纯的环境进行,还很可能是一个复杂的已投产的系统: 优化手段本来就有很大的风险,只不过你没能力意识到和预见到: 任何的技术可以解决一个问题,但必然存在带来一个问题的风险: 对于优化来说解决问题而带来的问题,控制在可接受的范围内才是有成果: 保持现状或出现更差的情况都是失败! 2.优化的需求? 稳定性和业务可持续性,通常比性能更重要: 优化不可避免涉及到变更,变更就有风险: 优化使性能变好,维持和变差是等概率事件: 切记优化,应该是各部门协…

四.基础优化 1.优化思路? 定位问题点吮吸:硬件-->系统-->应用-->数据库-->架构(高可用.读写分离.分库分表). 处理方向:明确优化目标.性能和安全的折中.防患未然. 2.硬件优化? 主机方面: 根据数据库类型,主机CPU选择.内存容量选择.磁盘选择: 1)平衡内存和磁盘资源: 2)随机的I/O和顺序的I/O: 3)主机 RAID卡的BBU(Battery Backup Unit)关闭. CPU的选择: CPU的两个关键因素:核数.主频 根据不同的业务类型进行选择: 1…

<uml大战需求分析>阅读笔记05 这次我主要阅读了这本书的第九十章,通过看这章的知识了解了不少的知识开发某系统的重要前提是:这个系统有谁在用?这些人通过这个系统能做什么事? 一般搞清楚这件事,再画个业务流程图,就能条例清楚的表达系统的需求了.作为一个开发人员,不仅要懂得如何从用户那里获取有用的信息,还要懂得怎么清晰地描述自己的想法,给客户呈现出一个结构完整.功能全面的系统原型.那么,这些必备的画图技巧,就会帮上很大的忙. 用例图是用处非常广泛,使用频率最高的UML图,它用来描述什么角色通过某…

前言   java工程师成长为架构师是一个艰难且耗费心力的过程,不仅仅需要熟悉java体系内相关的技术,同时要掌握许多运维相关的操作技能,随着k8s逐渐成为微服务持续集成开发难以越过的基础设施之后,docker就成为跨进门槛必备的技能之一.   虽然前两年kubernetes宣布v1.20开始弃用docker直到v1.23彻底排除,但这不意味着我们就要放弃学习docker,相反,国内诸多企业尤其是中小企业和事业单位存在大量用docker部署的既有项目,一些非互联网公司更是对升级版本十分审慎,大部…

正如飞机在起飞前,机长.副机长要过一遍checklist检查,确认没问题了才能起飞.楼主也整理了一个系统容量现状checklist,方便对照检查.本文搭配架构师必备:如何做容量预估和调优,食用更佳. 作为架构师,不要觉得系统容量是运维工程师才关心的问题,而应当对系统容量现状做到了如指掌.这样才能知道系统的瓶颈在哪,哪些优化是要优先做的,以及为了应对活动期间突发的流量,做多少扩容. 本文分为2大部分,一是资源使用率,二是业务指标. 资源使用率 服务实例 实例个数.每个实例server的工作线程个数…

日常工作中,MySQL数据库是必不可少的存储,其中读写分离基本是标配,而这背后需要MySQL开启主从同步,形成一主一从.或一主多从的架构,掌握主从同步的原理和知道如何实际应用,是一个架构师的必备技能.楼主将在本文做总结,看这一篇就够了. 1.主从同步原理 主从同步架构图(异步同步) 这是最常见的主从同步架构. 主从同步流程(异步同步) 主库把数据变更写入binlog文件 从库I/O线程发起dump请求 主库I/O线程推送binlog至从库 从库I/O线程写入本地的relay log文件(与bin…

最近看过几个程序员大学后一起创业,与大公司抢项目并成功逆袭的视频,感触颇深:第一.技术是关键:第二.有一群可靠并且技术超群的队友,在关键时刻不会掉链子:第三.善于部署谨慎周密的计划:第四.一流的口才+一流的领导者.他们的项目从小到大,从校园到自己的工作室,其中的辛酸也许只有经历过才能懂得. 项目成功的标准并不只是赚钱,更加不是不惜一切代价谋取最大利益,双赢才是最重要的原则.作为一个开发者,看到和团队一起努力出来的成果被众人使用,会有一种由心而生的成就感.自豪感,也许这就是happy成为程序员的原…

.NET架构师,我归纳一下要学的知识: 成为优秀程序员,需要学好的知识: 1. 面向对象编程.UML画图.设计模式.代码重构 2. 常用ORM工具 3.  MVC,WCF,XMl, JQuery ,SQL以及性能优化 4. FrameWork一些深入的知识 5. 高性能代码,比如静态化,MemCached等手段. 6. 最好也了解一些其他语言,比如Java,PHP等.…

前言 阅读地址 https://rootsongjc.gitbooks.io/kubernetes-handbook/content/concepts/ 架构 架构图说明: master 指服务端 1.etcd 是k8s的数据库 2.控制管理器 3.api管理器 4.调度器 node  指节点服务器 1.kubelet 节点应用 2.节点的kube-proxy 负责service的服务发现和负载均衡…

结论 有以下几种Redis集群方案,先说结论: Redis cluster:应当优先考虑使用Redis cluster. codis:旧项目如果仍在使用codis,可继续使用,但也推荐迁移到Redis cluster. twemproxy:不建议使用,与codis同为proxy方案,但不如codis(twemproxy不能平滑地扩容). 客户端分片:应当禁止使用,因为扩容复杂,如果2个服务同时读写,其中一个修改了路由,另一个不修改会有问题. 下面重点介绍Redis cluster和codis.…