架构

zabbix介绍 要想实时的了解服务器的运行状况并且能在出现问题时及时解决，利用监控软件是一个很好的选择，而zabbix监控系统则在众多监控软件中脱颖而出。 zabbix是一个基于web界面的企业级开源监控软件，Zabbix服务器需要LAMP环境或LNMP环境，提供分布式系统监控与网络监视功能。具备主机的性能监控，网络设备性能监控，数据库性能监控，多种告警方式，详细报表、图表的绘制等功能。监测对象可以是Linux或Windows服务器，也可以是路由器、交换机等网络设备，通过SNMP、zabbix Agent、PING、端口监视等方法提供对远程网络服务器等监控、数据收集等功能。 zabbix监控架构： 在生产环境中，zabbix根据网络环境、监控规模等外界因素分为三种架构：server-client（直接连接）、master-node-client（Node架构）、server-proxy-client（proxy架构），如下图所示： 1、server-client架构： server-client架构是zabbix最简单的架构，监控机和被监控机之间不经过任何代理，直接在zabbix server（监控服务器） 和zabbix agent（agent：部署在被监控端，用于采集数据）之间进行数据交互，适用于网络比较简单，设备较少的监控环境。 2、master-node-client架构

书评：软件设计精要与模式 终于阅读完了张逸先生的《软件设计精要与模式》一书，掩卷沉思，书中对于软件设计这门学问的理解和阐述让我受益良多，潜移默化之中，我对于软件设计的过程以及模式的使用又有了新的认识。因此，我对此书的评价是一本不可多得的优秀书籍。 不能光说优秀，到底优秀在何处呢？个人感觉有以下几点： 首先，内容不浮躁。 放眼当今的图书市场，很多书都被冠以《**天精通***》《***入门到精通》等等很诱惑人的题目，具体的内容却让人不敢恭维，看完全书之后，学到的都是最基本的知识，能够跟着书上的例子做几个简单的程序，甚至于还学会了其中一些不好的编程习惯，就飘飘然以为自己是开发高手了。浮躁是作为程序员的人所应当避免的，但正式很多书内容的浮躁，导致了人的浮躁。 而张逸先生的这本书则有很大的不同，里面并没有通篇列举大量初级的代码，他在书中提出的代码都是经过深思熟虑的，非常具有代表性的代码。并且，即便是在实例的部分，也没有直接给出最终的代码，而是先给出有问题的写法，然后逐步重构、改进，这个过程中不断地将软件设计的思想潜移默化地传递给读者，让读者理解其中的奥秘。另外，书中更多的是张逸先生对于软件设计和模式应用的理解和经验之谈，这在国内的书中是不多见的，这样的无私共享，与张逸先生本身的做人态度是分不开的。 其次，内容不枯燥。 很多做技术的人写起书来都是满篇的计算机术语，让人看了之后昏昏欲睡

现代化的企业私有云IT基础架构中，越来越多的生产环境正在逐步变革，将以传统虚拟化为中心的架构向以容器和微服务为中心的云原生架构过渡，在这个过程中，存储如何有效支撑各种云主机应用与微服务应用，对于企业的私有云数据中心提出了很大挑战。 杉岩容器云存储解决方案充分发挥了杉岩存储产品的云服务能力，具备广泛的生态合作基础，可高效地对接各种云化的计算资源，降低复杂私有云数据中心的基础架构层管理运维成本。 面临的挑战 业务调度变更频繁，资源不能共享 随着容器、微服务平台在企业私有云环境的上线，大型企业的应用快速开发迭代、发布频繁对于存储系统的弹性支撑能力提出了严峻挑战，且不同的业务数据保存在计算节点本地或者不同的外部存储设备中，数据流动性差，不仅导致存储空间及性能资源浪费严重，数据灾备方案难以统一。 开源产品难维护，无法实现企业级产品化 基于开源技术的容器编排系统如Kubernetes等为众多客户提供了快速构建PaaS平台的能力，但是存储部分却不一样，开源的存储系统如Ceph虽然可以在生产环境部署，但也面临一些问题：与硬件和企业级应用生态融合程度不高，严重依赖人工开发运维，在性能和服务质量方面不能同时满足敏态与稳态应用的需求。 存储接口需求多样化，没有统一的存储平台 容器平台中的中间件、数据库等需要持久化存储的业务通常直接使用块设备或文件夹，一些无状态应用则需要对象存储

什么是系统架构师？ 系统架构师是一个既需要掌控整体，又需要洞悉局部瓶颈，并依据具体的业务场景给出解决方案的团队领导型人物。一个架构师需要有足够的想像力,能把各种目标需求进行不同维度的扩展，为目标客户提供更为全面的需求清单。 架构师一直是程序员「羡慕且追求」的高度，今天来说说我眼里优秀的架构师该如何定义。毕竟我也曾经是一名架构师：） 在开始今天的话题之前我说一个和我前公司P9现在已经是P10的对话。 问题是这样的他说公司中间件架构师不熟悉公司业务，很多事落地不了，非常的疑惑。他最近主要任务就是和这些架构师聊天解惑：） 接着他说了一个类比的故事大概是这样的， 我们（架构师）要建设一条高速公路，来分别看看公路建造者（架构师）和司机（业务研发）的视角。 1，建造者 他们选用最好的沙子 水泥 更好的设计图纸和操作流程保证质量和处理异常情况（比如出入口提示，超车，紧急停车带） 2，司机同志 他们关心什么？ 司机关心路宽么，有堵车可以提前告知么。 司机关心路平整么？当然关心，关心。 引出一个的问题：司机（业务研发）关心用最好的水泥么 ？ 想象你是司机（业务研发）你你关心吗？ A，关心 B，不关心 欢迎留言留下你的思考。 系统架构师应具备哪些能力？ 我觉得一名优秀的架构师，在设计系统时需要有以下这四项关键能力：「平衡取舍、预判未来、抽象思维、容错机制」。 1.平衡取舍 一个架构本质上总会有优有劣

前言： 现在IT界跳槽已成常态，跳槽，可能有以下原因: 技术达到瓶颈，无法在此公司有好的提升，前几年我感觉基本不会出现，至少我现在没出现。 实力与薪资不匹配。 和同事 领导不和，如果你在几家公司都这样，要自我检讨一下是不是自己的问题。 仅个人观点，其他诸如地域 情感 兴趣等个人原因不做讨论。 这也导致很多企业在用人时会比较在意员工的稳定性一般外包公司都会比较忙，相对来说，成长应该是比较快的，而你的工作性质偏业务，那么你要想清楚一个问题，以后你的发展轨迹是怎样的？是在技术方向越走越远呢，还是在管理方向发展呢？ 一、 微服务架构专题（思维导图） 二、微服务是干什么的 我对于微服务最大的体会就是：对于云平台来说，如果元数据驱动的平台组件是骨骼，那么微服务和触发器就是串联骨骼的经络和血脉没有经络和血脉，一堆组件仅仅是静态的，不能变化，没有反馈，更何谈交互。而一个PaaS平台可以孵化无数个SaaS应用，每个应用都需要使用一套小服务来开发，而为了防止应用搭建复杂化和避免后期难以维护，所以每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP AP（Rest的方式，这就是为什么我能看到那些标签的存在）。好处体现在以下方面： 这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署（体现在平台就是微服务站点部署和独立微服务站点部署） 这些服务可以使用不同的编程语言实现（只要实现结果

来源： 51CTO 作者： 空空以空空 链接： https://blog.51cto.com/74949/2471807

1. 微服务简介 1.1 什么是微服务架构 微服务架构是系统架构上的一种设计风格 将大系统拆分成N个小型服务 这些小型服务都在各自的线程中运行 小服务间通过HTTP协议进行通信 有自己的数据存储、业务开发、自动化测试和独立部署机制 可以由不同语言编写 小结：微服务架构的思想，不只是停留在开发阶段，它贯穿了设计，研发，测试，发布，运维等各个软件生命周期。 2. 架构体系 架构样例： 2.1 微服务发布--持续集成 3. 微服务架构九大特性 服务组件化 -- 组件是可独立更换、升级的单元。就像PC中的内存，CPU一样。 按业务组织团队 -- 要求人员全栈技能 做“产品”的态度 -- 对整个产品生命周期负责，而不是做“项目”交付态度 智能端点与哑管道 -- 微服务间的通讯方式： --- HTTP的RESTful API --- MessageMQ消息队列 去中心化治理 --不是每一个问题都是钉子，不是每一个解决方案都是锤子。 去中心化数据管理 --独立维护各服务数据存储，尽量使服务间“无事物”调用，通过补偿机制维护数据一致性问题 基础设施自动化 -- 自动化测试 -- 自动化部署 容错设计 -- 每个服务实现监控和日志组件，比如服务状态，断路器状态，吞吐量，网络数据等关键数据仪表盘 演进式设计 --初期单体，逐步拆分，抽取公共组件 4. 微服务选型 Dubbo

设计高可用的软件架构，是每个互联网软件开发工程师的追求。尤其对于在线交易系统、在线广告系统而言，服务的可用性会直接影响商业变现。随着互联网技术在工业界的广泛使用，各大互联网公司在各自的业务领域内，沉淀了成熟的高可用架构方案。那么究竟什么是高可用？高可用架构该如何设计呢？ 度量 首先需要了解下什么是可用性以及如何度量可用性。对于一个交互式IT产品，是否可用是看用户能否用该产品完成他的任务。可用性就是在某个考察时间内，系统能够正常运行的概率或时间占有率的期望值。对于可用性等级，业内一般用n个9来描述，如下所示。 服务处于不可用状态的时间称为 故障时间 。可用性每提高一个等级，故障时间就要降一个数量级。从天到时到分，相对来说比较容易实现。再往后每提高一个等级，将付出成百上千倍的努力。大型网站服务通常至少做个4个9，做到5个9及以上就比较困难了。不仅要解决技术挑战，还要面对极大的成本压力。对于网站核心服务，会尽可能做到5个9，而非核心服务4个9，甚至3个9也可以接受。做技术决策时必须考虑 经济账 。 方法 那如何做到高可用呢？方法很简单： 冗余 。通俗讲，就是双保险机制。背后的理论基础是概率论。假设某个服务的可用性是99%（故障率1%），那么两个服务的可用性就是1-0.01*0.01=99.99%。可以看到，冗余对可用性的提升是 指数级 的。再冗余一个服务，可用性就达到6个9了。哇

虚拟化技术在企业私有云IT基础架构中仍然占据重要地位，同时，为了进一步提升应用效率，越来越多的生产环境也正在逐步变革，从以虚拟机为中心的架构向以容器和微服务为中心的云原生架构过渡，在这个过程中，存储如何有效支撑各种云主机应用与微服务应用，对于企业的私有云数据中心提出了新的挑战。 企业面临的问题 存储设施七国八制，硬件锁定缺少弹性 多种云平台对于存储的要求各不相同，块/文件/对象存储对应不同类型的应用，对外提供不同的服务接口，一种存储设备无法满足多种类型的云平台存储需求，而且传统存储在扩展性方面不能满足云时代大规模云平台对存储在线弹性扩容的需求，在可维护性方面则面临硬件架构绑定、运维复杂、难以维保等问题，而且这些问题会随着存储设备种类和数量的增多进一步放大。 业务调度变更频繁，资源不能共享 随着开发测试虚拟机以及容器、微服务平台在企业私有云平台的上线，大型企业的应用快速迭代、频繁发布对存储系统的支撑提出了严峻挑战，不同业务的数据保存在不同厂商的存储设备中，数据流动性差，不仅导致存储空间及性能资源浪费严重，数据灾备方案也很难统一化。 开源产品难以维护，不能实现企业级产品化 基于开源虚拟化技术的云平台如OpenStack为众多客户提供了快速构建私有云基础设施的能力，但是存储部分却不一样，开源的存储系统如Ceph虽然可以小规模部署试用， 但在大规模商用时会遇到很多问题

虚拟化技术在企业私有云IT基础架构中仍然占据重要地位，同时，为了进一步提升应用效率，越来越多的生产环境也正在逐步变革，从以虚拟机为中心的架构向以容器和微服务为中心的云原生架构过渡，在这个过程中，存储如何有效支撑各种云主机应用与微服务应用，对于企业的私有云数据中心提出了新的挑战。 企业面临的问题 存储设施七国八制，硬件锁定缺少弹性 多种云平台对于存储的要求各不相同，块/文件/对象存储对应不同类型的应用，对外提供不同的服务接口，一种存储设备无法满足多种类型的云平台存储需求，而且传统存储在扩展性方面不能满足云时代大规模云平台对存储在线弹性扩容的需求，在可维护性方面则面临硬件架构绑定、运维复杂、难以维保等问题，而且这些问题会随着存储设备种类和数量的增多进一步放大。 业务调度变更频繁，资源不能共享 随着开发测试虚拟机以及容器、微服务平台在企业私有云平台的上线，大型企业的应用快速迭代、频繁发布对存储系统的支撑提出了严峻挑战，不同业务的数据保存在不同厂商的存储设备中，数据流动性差，不仅导致存储空间及性能资源浪费严重，数据灾备方案也很难统一化。 开源产品难以维护，不能实现企业级产品化 基于开源虚拟化技术的云平台如OpenStack为众多客户提供了快速构建私有云基础设施的能力，但是存储部分却不一样，开源的存储系统如Ceph虽然可以小规模部署试用， 但在大规模商用时会遇到很多问题