架构运维

架构运维
最近经常在项目或是社区里听到大家谈论微服务架构，但谈论的焦点更多集中在微服务拆分，分布式架构，微服务门槛，DevOps配套设施等话题上。 但是在我眼里，真正能称之为微服务架构的少之又少。原因也很简单，我所见到的很多所谓的微服务架构项目，大多都没有做到微服务架构的一个基本要求：服务的独立部署（交付）。 这里的独立部署和自动化部署还不是一个概念，服务的自动化部署相对简单，已有大量的工具可以帮助我们做到。但是这里所谈的独立部署，我认为关键和难点并不在于“部署”，而在于“独立”。 如果失去了服务独立部署（交付）的能力，一个微服务架构的威力将大打折扣，我们的系统虽然在物理上被拆分成了多个小的服务，但是如果从最终交付的角度来看，仍然是以一个整体存在的，就像单体应用一样，存在诸多的问题。 为什么服务的独立交付并不简单？那为什么不能让每一个服务都独立部署到产品环境呢？问题的答案是：不是不能，而是不...

架构运维
编者按Google和Netflix联合发布了全新的开源Canary分析工具Kayenta。Canary(金丝雀部署)是现代Devops和持续交付中重要的一环，指的是把少量(通常1%-3%)的流量导到含有新版本的canary部署上运行一段时间并和当前的生产环境比较，再决定是否将新版本部署到所有机器的过程。转载请注明出处和原文链接。以下是项目代码: github.com/spinnaker/kayenta 为了成规模的实现持续交付，你不仅需要快速地发布软件更新，更需要能安全地发布。今天，Google和Netflix很高兴的发布Kayenta，一款开源的自动化Canary分析服务，该服务能让团队降低高速发布新部署时的相关风险。 由Google和Netflix联合开发的Kayenta是由Netflix内部的Canary系统进化而来，然后重新定义得完全开放，可扩展而且可以处理更多高级的用户...

架构运维
有很多网友留言：公司要做消息中间件选型，该如何选？你觉得哪个比较好？消息选型的确是一个大论题，实则说来话长的事情又如何长话短说。对此笔者专门撰稿一篇内功心法：如何看待消息中间件的选型，不过这篇只表其意未表其行，为了弥补这种缺陷，笔者最近特意重新撰稿一篇，以供参考。温馨提示：本文一万多字，建议先马（关注）后看。 一、前言消息队列中间件（简称消息中间件）是指利用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下提供应用解耦、弹性伸缩、冗余存储、流量削峰、异步通信、数据同步等等功能，其作为分布式系统架构中的一个重要组件，有着举足轻重的地位。 目前开源的消息中间件可谓是琳琅满目，能让大家耳熟能详的就有很多，比如ActiveMQ、RabbitMQ、Kafka、RocketMQ、ZeroMQ等。不管选择其...

架构运维
阅读对象传统企业正在做微服务架构转型的开发人员或者架构师，希望本文对您能起到一定的引导作用。 API网关介绍网关一词较早出现在网络设备里面，比如两个相互独立的局域网段之间通过路由器或者桥接设备进行通信， 这中间的路由或者桥接设备我们称之为网关。 相应的API网关将各系统对外暴露的服务聚合起来，所有要调用这些服务的系统都需要通过API网关进行访问，基于这种方式网关可以对API进行统一管控，例如：认证、鉴权、流量控制、协议转换、监控等等。 API网关的流行得益于近几年微服务架构的兴起，原本一个庞大的业务系统被拆分成许多粒度更小的系统进行独立部署和维护，这种模式势必会带来更多的跨系统交互，企业API的规模也会成倍增加，API网关（或者微服务网关）就逐渐成为了微服务架构的标配组件。 如下是我们整理的API网关的几种典型应用场景： 1、面向Web或者移动App 这类场景，在物理形态上类似前后...

架构运维
导读：Uber成长非常迅速，工程师团队快速扩充，据说Uber有2000名工程师，8000个代码仓库，部署了1000多个微服务。微服务架构是Uber应对技术团队快速增长，功能快速上线很出色的解决方案。本文偏向微服务的入门篇，以Uber微服务为例，进行了深入浅出的讲解。 微服务特性对于微服务没有适当的定义，你可以说它是一个框架，由小型的、独立的可部署的服务组成，执行不同的操作。 微服务专注于单个业务领域，可以作为完全独立的可部署服务，并在不同的技术栈上实现它们。 在使用微服务构建自己的应用程序之前，需要清楚地了解应用程序的范围和功能。 解耦 - 系统内的服务在很大程度上是解耦的。因此，整个应用程序可以轻松构建，更改和缩放 组件化 - 微服务被视为独立的组件，可以轻松替换和升级 业务能力 - 微服务非常简单，专注于单一功能 自治 - 开发人员和团队可以独立工作，从而提高速度 持续...

架构运维
摘要： 本文介绍了在使用阿里云Redis的开发规范，从键值设计、命令使用、客户端使用、相关工具等方面进行说明，通过本文的介绍可以减少使用Redis过程带来的问题。 一、键值设计1. key名设计 (1)【建议】: 可读性和可管理性 以业务名(或数据库名)为前缀(防止key冲突)，用冒号分隔，比如业务名:表名:id ugc:video:1 (2)【建议】：简洁性 保证语义的前提下，控制key的长度，当key较多时，内存占用也不容忽视，例如： user:{uid}:friends:messages:{mid}简化为u:{uid}:fr:m:{mid}。 (3)【强制】：不要包含特殊字符 反例：包含空格、换行、单双引号以及其他转义字符 2. value设计 (1)【强制】：拒绝bigkey(防止网卡流...

架构运维
前言近来有很多网友留言：公司要做消息中间件选型，该如何选？你哪个比较好？我的回答一般是：It’s a nice topic~如果随意回答一个的话显得很不严谨也不太负责任，如果严谨的回答的话一天就不用干活了。消息选型的确是一个大论题，实则说来话长的事情又如何长话短说。被问的越多越觉得需要整理一篇自己的观点出来，主要的目的将自己的经验分享出来，可以让别人少踩点误区，次要的目的是下次再被问到了可以直接甩链接而不用再打太极（如果你后者觉得这是主要目的话，那么我只能回答：橘生淮南则为橘，嘿嘿~~）。不过本文的主要内容为观点表达（别名：“吹水”），不涉及具体的技术细节。 历程目前大多数所用的、所讨论的（Fashion的）消息中间件大致为Kafka、RabbitMQ和RocketMQ这三种，本文尽量站在一个中立的视角上去看待这个问题。当然如果你说市面上的MQ多了去了，比如还有ActiveMQ、Ze...

架构运维
技术雷达：现在越来越多的大型组织在向更加自组织的团队结构转型，这些团队拥有并运营自己的微服务，但他们如何在不依赖集中式托管的基础架构下，确保服务之间必要的一致性与兼容性呢？为了确保服务之间的有效协作，即使是自组织的微服务也需要与一些组织标准对齐。服务啮合(SERVICE MESH)在服务发现、安全、跟踪、监控与故障处理方面提供了一致性，且不需要像API网关或ESB这样的共享资产。服务啮合的一个典型实现包含轻量级反向代理进程，这些进程可能伴随每个服务进程一起被部署在单独的容器中。反向代理会和服务注册表、身份提供者和日志聚合器等进行通信。通过该代理的共享实现（而非共享的运行时实例），我们可以获得服务的互操作性和可观测性。一段时间以来，我们一直主张去中心化的微服务管理方法，也很高兴看到服务啮合这种一致性模式的出现。随着linkerd和Istio等开源项目的成熟，服务啮合的实现将更加容易。...

架构运维
在这篇文章中将我们一起来探讨当前的API网关的现状和未来。 一. API网关的用处API网关我的分析中会用到以下三种场景。 1.Open API。 企业需要将自身数据、能力等作为开发平台向外开放，通常会以rest的方式向外提供，最好的例子就是淘宝开放平台、腾讯公司的QQ开放平台、微信开放平台。 Open API开放平台必然涉及到客户应用的接入、API权限的管理、调用次数管理等，必然会有一个统一的入口进行管理，这正是API网关可以发挥作用的时候。 2.微服务网关。 微服务的概念最早在2012年提出，在Martin Fowler的大力推广下，微服务在2014年后得到了大力发展。 在微服务架构中，有一个组件可以说是必不可少的，那就是微服务网关，微服务网关处理了负载均衡，缓存，路由，访问控制，服务代理，监控，日志等。API网关在微服务架构中正是以微服务网关的身份存在。 3.API...

架构运维
2017年是“微服务”疯狂的一年，如同股灾前的狂欢，各种不同行业的技术团队都在宣讲着自己微服务实践的道路。然而大家是否有反思过自己真的在玩“微服务”吗？您真的在“微服务”中受益了吗？还是为了凑这波的热点，而被折腾的疲惫不堪？ 下面的内容是《The Death of Microservice Madness in 2018》一文的翻译，本文很好地阐述了“微服务”在带来诸多优势的同时也对技术团队增加的复杂度所带来的挑战。各个技术团队Leader们，是时候好好思考一下，在这一波的疯狂中，您的团队是否都做到位了？还是又充当了一回“时髦架构师”？ ——程序猿DD 微服务在过去几年一直是一个非常热门的话题（附录1）。何为“微服务的疯狂”，举个例子： 众所周知，Netflix在DevOps上的表现非常棒。Netfix可以做微服务。因此：如果我做微服务，我也将非常擅长DevOps。 很多情况...

架构运维
开篇： 如果在诸多热门云计算技术中，诸如容器、微服务、DevOps、OpenStack 等，找出一个最火的方向，那么非微服务莫属。尽管话题炙手可热，但对传统行业来说，微服务落地和方法论目前处于起步阶段。 本报告于2017年11月份展开，从驱动因素、落地现状、和容器关系、架构体系、未来趋势和落地方法论等方面对微服务进行了分析。希望能够为传统企业微服务决策、规划和实施提供依据和解决办法。 驱动因素传统行业对IT效率的变革需求是微服务成长土壤,业务模式创新重塑导致系统更新频繁、应用复杂度急剧升高，传统架构不堪重负。 微服务架构具有明显的好处，尤其是在应对复杂业务系统的多变需求方面。在本次调研企业中，每个月都要进行业务系统更新的比例占63%，只有不到20%的企业半年以上更新一次系统。 加快互联网+步伐成为许多传统企业的必然选择。业务场景、用户习惯和行为在迅速变化，许多传统行业线上业务出...

架构运维
将应用程序部署到 Kubernetes 时，有很多选择。像 Helm 和 Ksonnet 这样的工具使得打包应用程序并将其部署到多个 Kubernetes 环境变得非常简单。但是，这些工具只能解决部分问题。部署到生产很少像 helm install my-chart 一样如此简单。他们可以涉及多个步骤，并保证所涉及的应用程序正常运行。我从 Kubernetes 用户那里听到的一个最常见的问题是“如何部署我的数据库变更？”。这是我一遍又一遍地问自己的问题。在 Skuid ，我们花了很多时间试图找出最安全和高可用的方式来执行这些数据库迁移，作为我们部署 Pipeline 的一部分。我们写的代码来做到这一小步在我们的 Pipeline 步骤是很复杂的。 使用 Spinnaker，我们能够使这一步骤可重复，安全和可靠。在本教程中，我将解释如何设置一个简单的部署 Pipeline 来运行我们...

架构运维
Spinnaker 的介绍 Spinnaker 是 Netflix 开源出来的持续交付工具，目的是为研发团队提供灵活的持续交付流水线，并且支持部署到测试/生产环境。Netflix 目前通过 Spinnaker 实现每天4000次的发布。它的优势在于： 支持多种云平台。目前支持 AWS EC2（Netflix 的机器大部分都在亚马逊），谷歌云，Kubernetes，Azure，Openstack 等，目前正在支持甲骨文的物理机和 DC/OS。 自动化发布。可以集成测试脚本进行测试，并且能够管理测试，线上环境的机器，实现动态扩容，和服务的下线。 发布原子化。由于 Netflix 的平台已经实现微服务化，每个团队使用 Spinnaker 独立维护服务的发布，所以 Spinnaker 的设计特别适合于微服务持续交付的场景。 预置了软件发布的最佳实践。通过脚本实现不可变基础设施，使得发布时候...

架构运维
MySQL 是世界上最流行的开源数据库系统，MariaDB(一个 MySQL 分支)是世界上增长最快的开源数据库系统。在安装 MySQL 服务器之后，在默认配置下是不安全的，确保数据库安全通常是通用数据库管理的基本任务之一。 这将有助于增强和提升整个 Linux 服务器的安全性，因为攻击者总是扫描系统任意部分的漏洞，而数据库在过去是重点目标区域。一个常见的例子是对 MySQL 数据库的 root 密码的强制破解。 在本指南中，我们将会讲解对开发者有帮助的 MySQL/MariaDB 的 Linux 最佳安全实践。 1. 安全地安装 MySQL这是安装 MySQL 服务器后第一个建议的步骤，用于保护数据库服务器。这个脚本可以帮助您提高 MySQL 服务器的安全性： 如果您在安装期间没有设置 root 帐户的密码，马上设置它 通过删除可从本地主机外部访问的 root 帐户来禁用远程 r...

架构运维
如果在诸多热门云计算技术中，诸如容器、微服务、DevOps等，找出一个最火的方向，那么非微服务莫属。在小数推荐的这篇文章里，做与不做微服务好像理由都很充分。另外，诞生几十年的康威定律，在组织结构调整和变革方面，依然神采奕奕。 创建一种新的软件项目架构，来封装离散服务，对于全新的项目来说，这是非常简单的。但是，对于大多数软件开发者来说，谁又有大把的奢侈时间一直用在全新项目上呢？ 大多数软件开发人员职责更多是维护或增加现有软件系统的功能。但是，如果问开发人员究竟是愿意构建全新的项目，还是维护一个现有的系统，那么支持新项目的呼声肯定会成为压倒性的声音。事实上，希望与新技术或新项目合作也是开发人员离职的原因之一。为什么呢？ 1. 识别问题容易，但修复很难维护现有系统时，很容易识别架构的问题。为什么？因为基于良好的架构，系统很容易调整。 当需要去调整一个没有设计封装波动的已有系统时，架构的...