什么时候需要使用架构原则?
1:架构设计
2:项目验收
总结:诸事不决,架构原则
架构设计原则
1:体系安全
2:成本合理
3:稳定可靠
4:性能适用
5:运维高效
体系安全
1:根据系统的合规标准设定目标
1.1:合规标准:1,国际标准;2,国家标准;3,行业标准;4,公司要求
2:成体系地规划系统的整体安全
3:在所有层次实现安全性
4:风险评估并准备应对预案
成本合理
1:持续观察评估
1.1 我们应该争取每年都做到一次费用的降低
2:使用托管服务
2.1 托管服务如:云数据库等等paas产品,虽然看起来单价很贵,但是包含的价值很多。
3:临时资源
3.1搭建函数计算等,调用即收费等资源
4:多层次优化成本
4.1 从整理架构设计,购买方案来达到成本优化的目的
总结:我们的架构不但能工作,最好能不花钱
架构可靠
1:根据业务需要设定可靠性指标
2:为了失败做设计才能保持不败
3:避免单点故障
4:在架构中实现松耦合
5:预测故障形式并准备应对预案
总结:所有东西都会坏,坏了这个架构也能自己恢复
性能适用
1:根据业务需要确定性能指标
2:了解先进技术并合理选择
3:寻找数据特点和热度,设计缓存
4:系统实现弹性
总结:性能不用极致,超过需求一点点就好
运维高效
1:做好监控对系统了如指掌
1.1 一定要用好云上的监控
2:自动化减少人工的风险
3:更新或是替换跳出旧思想束缚
4:减少底层维护聚焦应用层维护
4.1 可以的话,使用容器,微服务架构
总结:好的架构,应该可以实现,并容易维护
如何做到服务器安全?
1:数据静态安全
使用云硬盘的数据盘加密,本地硬盘可以操作系统内加密
2:数据动态安全
https数据传递
3:网络安全
3.1 VPC控制网络安全
3.2 控制本机打开的端口;启用本机操作系统防火墙
3.2.1 只放行需要的提供业务的端口,其它端口关闭。启动系统防火墙
3.3 使用主机安全服务,DDOS攻击保护,架构保护
3.4 访问控制:
密码访问(不推荐);
密钥对访问(推荐);
或者在服务器环境部署完成之后,关闭服务器远程登录
3.5 审计和跟踪
使用日志服务收集日志
应用程序内的日志管理
3.6 事件响应
主机恢复流程设计和应对练习
如何优化服务器成本?
1:选择合适主机类型
2:不用就关机
关机可以释放CPU,内存资源
3:灵活组合购买方案
综合考虑:按需计费,包年包月,竞价实例
4:费用由主机运行时间,流量费组成
4.1 流量费,流入免费,私网流出到同区域免费
4.2 平衡流量和算力之间的关系
如何确保服务器可靠性?
1:云服务器是单点,需要假设会损坏做设计
2:选择云服务器组的反亲和性,避免接近部署
3:需要集群化分布式安排服务器
如何确保服务器性能?
1:使用监控
2:性能与应用特性
3:AZ内和跨AZ的网络延迟不同
4:EVS的性能选择
EVS的IOPS和带宽较难同时达到
5:很多时候服务器在等待数据
服务器可维护性考虑
1:用户需要维护云服务器
2:操作系统补丁
3:应用软件升级
4:自建应用程序升级
5:数据备份,主机备份
6:其它安全的维护
如何去检查架构是不是符合架构设计原则?--安全
1:我们在架构上每一层的网络安全设计是什么样的
2:整个体系的身份认证和权限边界是什么样的
3:运行中如何检查和评估安全风险
4:如何保护计算资源,防止被侵占
5:数据如何分级,各级别的安全设置,能否自动化定级?生命周期规则?
5.1 不同级别的数据在静态如何保护
5.2 不同级别的数据在传输中如何保护
6:当安全事件发生时,如何探测,响应从而恢复?
如何去检查架构是不是符合架构设计原则?--成本
1:我们是不是使用了托管服务而不是自建组件?
2:我们是如何去管理我们的资源使用的?
2.1 如何讲成本归拢到产品线,成本中心等负责实体上?
2.2 我们如何管控资源的使用原因,时长和最后的开销?
2.3 我们如何管理资源生命周期,从而及时关闭终期资源?
3:在组件服务选择的时候,我们有没有去评估成本?
4:我们是如何评估,计算来决策计算模式选择的?
5:资源的使用重心是在哪里?如何去针对重点开销做优化?
如何去检查架构是不是符合架构设计原则?--可靠性
1:服务限额和其它限制是如何管理的?
2:网络拓扑是如何规划的,如果链路损失如何响应
3:是否需要设计一个分布式系统防止组件损坏
4:如何进行变更?如何确保定期变更及时被执行
5:根据不同的数据分级,如何备份和恢复这些数据
数据可靠性指标如何
备份恢复的测试
6:容灾的规划是什么样的?如何测试可靠性?
如何去检查架构是不是符合架构设计原则?--性能
1:我们定义了各个模块需要的性能指标了吗?
2:我们已经选择了最优的组件了吗?
我们选对了计算实例的类型了吗?
我们选对了存储方案和存储配置了吗?
我们选对了数据库方案了吗?
我们是不是使用了托管服务而不是自建组件?
我们考虑过新型的服务组件了吗?
3:我们的组件已经按期待的性能在工作了吗?
如何去检查架构是不是符合架构设计原则?--运维
1:我们如何感知应用程序在运行时候的状态指标
2:我们如何降低部署这个架构时候的风险
3:我们是否知道这个应用环境是否在健康工作
4:我们需要做那些维护工作?何时进行维护?有没有记录?如何降低维护操作异常的风险?维护对业务持续性有何影响?
5:我们需要安排那些运维流程来管理对资源的使用?
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/127942.html
摘要:阿里巴巴的共享服务理念以及企业级互联网架构建设的思路,给这些企业带来了不少新的思路,这也是我最终决定写这本书的最主要原因。尽在双阿里巴巴技术演进与超越是迄今唯一由阿里巴巴集团官方出品全面阐述双八年以来在技术和商业上演进和创新历程的书籍。 showImg(https://segmentfault.com/img/remote/1460000015386860); 1、大型网站技术架构:核...
摘要:由于文章内容较长,所以我把它分成两篇小文章,在第一篇优秀架构师必须掌握的架构思维中,我会先介绍抽象分层分治和演化这四种应对复杂性的基本思维。另外,上面的算法是两路归并,也可以采用多路归并,甚至是采用堆排序进行优化,但是总体分治思路没有变化。 showImg(https://segmentfault.com/img/bVbeYpP?w=642&h=400); 介绍 架构的本质是管理复杂性...
摘要:由于文章内容较长,所以我把它分成两篇小文章,在第一篇优秀架构师必须掌握的架构思维中,我会先介绍抽象分层分治和演化这四种应对复杂性的基本思维。另外,上面的算法是两路归并,也可以采用多路归并,甚至是采用堆排序进行优化,但是总体分治思路没有变化。 showImg(https://segmentfault.com/img/bVbeYpP?w=642&h=400); 介绍 架构的本质是管理复杂性...
摘要:本篇文章来自于腾讯和共同举办的技术开放日后台专场出品人傅鸿城的分享,由壹佰案例整理编辑。对于腾讯而言,后台服务可用性都是四个九,四个九转化为时间就要求一年内的故障时间不能超过分钟。 showImg(https://segmentfault.com/img/bVvL5f); 本篇文章来自于腾讯SNG和msup共同举办的技术开放日后台专场出品人傅鸿城的分享,由壹佰案例整理编辑。原文发布在壹...
阅读 284·2024-11-07 18:25
阅读 130363·2024-02-01 10:43
阅读 868·2024-01-31 14:58
阅读 828·2024-01-31 14:54
阅读 82766·2024-01-29 17:11
阅读 3047·2024-01-25 14:55
阅读 1985·2023-06-02 13:36
阅读 3032·2023-05-23 10:26