devops

如何统一看待和区别分层架构、微服务架构、分布式架构等主流架构？什么是 SOA？我们采用 SOA 的目的是什么？什么是服务化的本质？如何设计服务以及服务化架构呢？本文，阿里高级技术专家程彦将分享他对面向服务架构的一些看法，并给出相关的步骤和方案。 自从提倡 SOA 架构风格以来，个人觉得软件架构并未有特别突破的变革，主要是在 SOA 面向服务架构风格基础上不断演化迭代，基于服务的 EA 明确分层架构也好，微服务也罢，都是在面向服务架构基础上的适应不同的场景的迭代升级。 我先抛出一个观点，我觉得服务化架构的本质，和西方教育界深受影响的古希腊哲学家苏格拉底的“产婆术”的教育思想本质上是非常相通的：苏格拉底的“产婆术”思想强调教育是一个“接生”的过程，教师就是“接生婆”，人们之所以接受教育是为了寻找“原我”以不断完善自身。也就是教育的目的在于唤醒而不再于塑造。 同理服务化架构的本质也不仅仅在采用什么样的技术框架实现和塑造，更重要的是在于通过不停地在共创中反问、反思、反省等方式进行对业务的本质的不断追溯、抽象、综合归纳演绎，我们的每一个架构师都是服务化架构的接生婆，我们的使命是建立真正反映业务本质并驱动业务不断向前的架构。 我们是否足够深入理解业务的本质，做了足够的归纳演绎以及综合抽象，是否清晰的反应到了我们的服务化的根基：业务模型、域模型以及平台公共语义模型上

技术只是基础 　　该系列的两篇文章《 .Net微服务实战之技术选型篇 》和《 .Net微服务实战之技术架构分层篇 》都是以技术角度出发描述微服务架构的实施。 　　如果技术选型篇叙述的是 工具 ，那么架构分层篇讲的就是 技巧 ，而本篇要讨论的就是 原则 。一直以来我会给身边向我探讨问题的人灌输一种理念，没有什么技术银弹，因为我们做的是软件工程，提供的是问题相应的解决方案，不同类型问题的解决方案是存在着本质上的差异。 　　继续提供之前的源码：https://github.com/SkyChenSky/Sikiro PS：该篇文章与.Net无关，其实主要是沿用前面两篇文章的命名，此外我认为DevOps不是简单的工具使用，应从软件工程角度进行出发。 什么才是优秀的架构设计？ 　　曾经有好几个同行问过我同一个问题：什么才是优秀的架构设计？我一直信奉着 两句话 和 一个定律 ： 架构服务于业务，技术服务于架构 康威定律（简单理解成组织架构的设计等同于系统架构的设计） 　　 架构设计 其实就是一种 方案 的 取舍 ，在 有限 的 资源 里(包括但不限人力、时间)能让 团队 顺利的实施技术，同时满足 业务规模 的需要，我认为可以称之为优秀的架构设计，简单来说两个字 合适 架构核心要素 　　核心的主要5大： 性能、可用性、伸缩性、扩展性、安全性 。 　　而我们所讨论的微服务，选择了扩展性

“ 两个项目的直接对比，充分说明即使是假敏捷都比瀑布优秀。 ” 01 假敏捷的“猎狗” “猎狗”项目始于2019年初，当时公司签了一个大客户，并十分激进地计划在2019年10月份上线。据说，公司和客户签的协议还蛮严苛的，延期交付是要被客户被罚款的。 这个项目的复杂度很高，其业务模式和在我们系统上运行的现有业务也不一样。交付风险非常高。 为了尽快启动开发，项目组临时招聘了大量熟悉该业务的业务人员和开发人员，他们对新业务很熟悉，但对我们的系统和内部业务流程则一无所知。 项目组也决定完全采用敏捷开发的方式进行管理。每五个星期为一个迭代。 之所以迭代周期那么长，是因为核心系统是由第三方开发的，又是一个复杂的单体系统，还要顾及现有业务，开发难度大、风险高。原计划每个迭代预留两周做开发，两周做业务验收测试，一周做回归测试。 公司高层对这个项目非常重视，因为这是我们最重要的客户之一。而且，公司一直在推动敏捷转型，也想把这个项目做成敏捷开发的“模范家庭”，证明如此复杂、依赖第三方开发的项目也可以实现敏捷开发，其他更简单的项目就别再唧唧哇哇地找借口不转型了。 初心是好的，但现实很残酷。这个项目很快陷入了泥潭。 前面提到，由于在项目组中，不管是参与的业务人员还是开发人员，都是新聘的，他们对我们的环境完全不熟悉，需求难以落地，缺乏全局视角，很多坑没有预见。此时不得不临时抽调我们团队的“老司机”去救火

技术只是基础 　　该系列的两篇文章《 .Net微服务实战之技术选型篇 》和《 .Net微服务实战之技术架构分层篇 》都是以技术角度出发描述微服务架构的实施。 　　如果技术选型篇叙述的是 工具 ，那么架构分层篇讲的就是 技巧 ，而本篇要讨论的就是 原则 。一直以来我会给身边向我探讨问题的人灌输一种理念，没有什么技术银弹，因为我们做的是软件工程，提供的是问题相应的解决方案，不同类型问题的解决方案是存在着本质上的差异。 　　继续提供之前的源码：https://github.com/SkyChenSky/Sikiro PS：该篇文章与.Net无关，其实主要是沿用前面两篇文章的命名，此外我认为DevOps不是简单的工具使用，应从软件工程角度进行出发。 什么才是优秀的架构设计？ 　　曾经有好几个同行问过我同一个问题：什么才是优秀的架构设计？我一直信奉着 两句话 和 一个定律 ： 架构服务于业务，技术服务于架构 康威定律（简单理解成组织架构的设计等同于系统架构的设计） 　　 架构设计 其实就是一种 方案 的 取舍 ，在 有限 的 资源 里(包括但不限人力、时间)能让 团队 顺利的实施技术，同时满足 业务规模 的需要，我认为可以称之为优秀的架构设计，简单来说两个字 合适 架构核心要素 　　核心的主要5大： 性能、可用性、伸缩性、扩展性、安全性 。 　　而我们所讨论的微服务，选择了扩展性

来源：FreeBuf，Alpha_h4ck，版权归原著作者所有 原文：https://www.freebuf.com/articles/terminal/195694.html 写在前面的话 ​容器和微服务技术的诞生为我们设计和构建安全的基础设施以及应用程序提供了非常大的帮助。容器环境从中心化到数字化的转变，正在迅速成为主流。基于云环境的原生架构以及基于微服务的应用程序对于公司和企业的快速发展至关重要。为了快速实现安全性，企业必须加快自身的容器安全策略以及实施的成熟度。 随着生产部署速度的加快，不同组件之间的安全问题愈发明显，这将给企业带来直接的安全风险。大家都知道，传统的安全工具及产品无法给容器和微服务提供安全保护，因此大多数部署了容器的公司都会对自身资产的安全性表示担忧，并且希望安全社区能够提供专门的解决方案。 除了部署新的容器安全平台之外，各大公司还意识到了他们必须利用云环境和容器化生态系统固有的安全功能及架构，而类似Kubernetes这样的容器及微服务技术就给我们构建安全的基础设施以及应用程序提供了绝佳的机会。 新的挑战和策略转移 从本质上来看，容器化环境只要在构建和使用时操作得当，那它们就是更安全的。但想要安全地配置、操作和运行这些系统，就需要丰富的经验了。通常，一般的安全团队对容器或Kubernetes这样的东西是没有经验的

离线安装集群 参考 https://github.com/easzlab/kubeasz/blob/master/docs/setup/offline_install.md 离线文件准备 在一台能够访问互联网的服务器上执行： 下载工具脚本easzup，举例使用kubeasz版本2.2 export release=2.2.1 curl -C- -fLO --retry 3 https://github.com/easzlab/kubeasz/releases/download/${release}/easzup chmod +x ./easzup 使用工具脚本下载 默认下载最新推荐k8s/docker等版本，使用命令 ./easzup 查看工具脚本的帮助信息 # 举例使用 k8s 版本 v1.18.2，docker 19.03.5 ./easzup -D -d 19.03.5 -k v1.18.2 # 下载离线系统软件包 ./easzup -P 执行成功后，所有文件均已整理好放入目录/etc/ansible ，只要把该目录整体复制到任何离线的机器上，即可开始安装集群，离线文件包括： /etc/ansible 包含 kubeasz 版本为 ${release} 的发布代码 /etc/ansible/bin 包含 k8s/etcd/docker/cni 等二进制文件 /etc

作者介绍 赵辉， 前HSBC商业银行DevOps团队主管，DevOps专家，现任一线公有云企业DevOps平台解决方案架构师。 ​当下的IT领域，持续测试是成功采用DevOps交付模式的关键因素。持续交付的目标，是能够快速和持续地反馈符合客户需求的高质量产品。 然而，理想很丰满，现实很骨感。自从2012年，第一份DevOps报告由Alana Brown发布之后，DevOps开始逐渐获得业界的认知。越来越多来自各领域和产业的IT团队开始谈论DevOps和数字化转型，其中不少团队已经根据自身对DevOps的理解采取了行动。根据哈佛商业评论的数据，在2019年大约有70%的转型项目失败，而失败的原因与其DevOps落地的情况有着很强的相关性。 本文我们具体来看看，现阶段持续测试是如何帮助团队成功落地并实现DevOps转型的。 一、避免中心化的测试团队 传统上来说，QA、开发和产品Owner隶属于不同的团队，即烟囱式的中心化团队。当开发完成一个功能需求的开发之后，QA团队才开始测试用例的设计，并且执行对应的测试用例，无论是手工测试还是自动化测试。当所有的测试工作结束后，产品负责人会验收这个新开发的功能是否符合预期。通常在这种开发模式下，QA团队或者产品Onwer的反馈已经晚了，因为代码已经被合并到了主干，导致任何代码的变化将造成的成本已经高出了大多数人的预期

目录 前言 为什么在生产上主从环境情况下mySQL特别容易卡死 不要去怪设计不要去怪开发我们devops靠自己 场景一、当要被删除的数据量远大于保留的数据量的场景下的做法 操作涉及数据量及环境 烂机器环境下的执行情况 好机器环境下的执行情况 场景二、当要被删除的数据量远小于保留的数据量的场景下的做法 分场景1、被删除的数据很小小到只会引起10分钟内的主从延迟-不建议 操作涉及数据量及环境 烂机器环境下的执行情况 好机器环境下的执行情况 分场景2、被删除的数据不小，但是如果直接delete一定会引起15分钟以上的主从延迟 烂机器环境下的执行情况 好机器环境下的执行情况 最终对于生产mysql的日志清理策略的best practice 附录 自动监控mysql主从延迟报警shell脚本-behind_master.sh 使用CentOS的crontab设置监控脚本每5s运行一次写法 自动发送告警信息到企业微信接口（aldi-cupidmq）的python脚本 企业微信收到主从延迟后的展示效果 前言 本方案适合：无关业务的“日志数据”，但往往日志数据是最最占用我们的整体系统性能的，因此对这样的日志，我们是需要进行定期清理的。 如果你要说：业务数据也需要那么我告诉你， 业务数据肯定用的是本方案中的场景2中的分场景2模式（只有这一条路） ，但是业务数据会暴发到你连本方案都无法覆盖的那一天的

.Net Conf: Focus on Microservices 是 .Net Conf 社区在 2020 年 7 月 30 日举办的线上分享活动。整个活动视频长达近 10 个小时。今天我们来看看都发生了什么。 章节汇总 本次分享由十多位来自全球的资深技术专家在线分享，涵盖了当前 .Net 在微服务领域的利器。包括有以下这些内容： .Net 最新特性与微服务 为何关注微服务（Why You Should Care About Microservices） 保持技术敏锐（Stay Sharp） 使用 Steeltoe 开启 .NET 微服务旅程（A Journey into .NET Microservices with Steeltoe） Orleans 在微软中的应用（Orleans at Microsoft） DARP 助力您的 .NET 微服务（Adding a Little DAPR to Your .NET Microservices） Tye 让您快乐开发微服务（Developing and Deploying Microservices With ‘Tye’） 不仅只有 REST 和 RPC，还有异步事件和消息模式（Beyond REST and RPC：Asynchronous Eventing and Messiging Patterns） 微服务、DDD 和

河北建工集团通过BuildRun构建智慧工地，管理建筑项目从规划、设计开始到施工、运维的全生命周期，推进产业链数字化、在线化、智能化，上达企业下至工地项目，建立完整的数据沟通体系。在提升IT效能的同时，帮助企业实现精细化、智慧化数字施工，全方位、全链路提升工程建造的整体运营效率，促进产业升级。 BuildRun致力打造“数字建筑”，提供低代码应用开发平台，帮助企业搭建统一、完整、基础的企业业务中台，统一技术栈，以统一的技术规范和开发管理规范指导后续应用的开发，目前已上线BIM管理、安全管理等企业级应用，正逐步完善智慧工地系统，助力建筑行业产业转型升级。 河北建工集团智慧工地系统—— 劳务管理， 2020年8月正式上线投入使用 劳务管理是智慧工地系统中承接人员和工作管理的重要一环，通过数字化劳务管理，改变传统工地管理混乱，人员管理松散，劳工纠纷尖锐，项目风险居高不下的现状，将人员、资产和财务信息高度集成，对接国家和各省市劳务实名制平台，统筹管理集团及子公司的劳工，实现组织内外的智慧互联。 功能一览 劳务管理涉及劳务实名制管理系统、考勤机对接平台、集团工人数据库三大部分，包括人员管理（工人数据库）、考勤管理、工资管理、考勤机管理、人员行为记录等功能，连通PC端、平板端、手机端三种终端，实时进行信息录入与维护，同时可通过现场大屏设备呈现数据情况，辅助人员监管和计划调配。 01 人员管理