导言如今，很多科技企业都投入了对机器学习技术的研究和应用中。但是面临的情况可能是组织已经在本地使用机器学习，但还不能够将其部署到生产环境中；或者能够部署模型，但无法对其进行有效管理。在这种情况下，最有价值的技能不是训练模型，而是管理模型，并以让它们产生最大影响的方式部署它们。了解模型开发生命周期通常机器学习或模型开发遵循以下路径：数据→信息→知识→洞察力。这种从数据中产生洞察力的方式可以用下图来形
一、背景【用户画像运营分析系统】是利用用户的“一切”线上行为可追溯、可分析的特点，完成对用户多维度数据的完备收集和挖掘研究，让用户的特点和行为在企业面前都做到“可视化”，形成“用户画像”。从而达成以下商业目标：为企业的经营分析服务；针对用户进行精细化运营服务；针对用户进行个性化推荐、精准营销、个性化客服等多样化服务，深入挖掘潜在的商业价值；一些应用场景!image.png(https://s2.5
导言最近有小半年由近半数工作和生活时间在机器学习技术（ML）的学习与工程实践中，感觉自己阅读了几本ML方面好书，找到了一些更好的学习网站，所以重新梳理了一下自己理解的的ML基础知识。相关参考摘录书籍及网站如下《机器学习实战：基于ScikitLearn、Keras和TensorFlow》（第2版）《Python深度学习》（第2版）网站：<https://www.showmeai.tech/一、机器学
一、背景：期待解决的问题一年多之前，在经历了不成功的创业之旅后，回到了之前的企业，负责集团互联网业务的产研工作。彼时，在产研层面我们面临着以下问题:（一）在企业视角期待解决的问题1.产品交付质量的提升刻不容缓产品平台注册用户已达千余万，日均活跃用户稳定在百万左右，虽然问题和故障发生率和出现频率不高，但是在大体量用户下的客诉问题依然给市场和内部运营带来了诸多负担。更为严重的是，在市场增长关键期因为大
导言在前面的文章《「大数据技术体系」学习实践导览》(https://blog.51cto.com/yaocoder/5711005)中，概要式的梳理了大数据平台的业务目标，大数据平台的架构框架，大数据平台中常用的技术及工具，数据治理四方面的内容，算是对自身所了解大数据知识体系的抛砖引玉。今天想以自身的经历和实践经验，分享一下大数据平台的技术生态、开发管理与应用架构。为求简明扼要，内容主要以图示概览
导言：先谈谈在企业深度实践Kubernetes后的一些体会：1.作为一个有过数年微服务编写、运维经历的工程师，我认为使用Kubernetes可以最大化增益微服务的可靠性及服务治理工作。2.作为一个有过数年在团队提倡和推行DevOps持续交付理念的技术管理者，在使用Kubernetes后才真正在团队落地了DevOps全流程。3.在这些过程中，我和团队还有一个更大的体会：Kubernetes极大的提升
导言截止目前为止，在自己的技术生涯中，要说哪一种技术体系的学习路径最为曲折，那非大数据技术体系莫属了。相比特定编程语言的学习，相比类如云原生技术这类已然涵盖面很广的技术体系，个人感觉大数据技术的体系“繁杂度”高出了几个量级。具体原因并不是因为大数据技术体系的“难度”，而是因为其“广度”和“自由度”。“广度”——在多年的历史发展和众多企业的参与中，大数据技术及工具的门类极其繁多，特性差异化多且很多体
导言：之前在文章《云原生核心技术之：容器Docker》(https://blog.51cto.com/yaocoder/5458828)中梳理了容器技术产生的背景、Docker技术简介。其实Docker技术的实际应用也很简单，今天这篇文章便用一个python环境“helloworld！”服务来进行示例。相应的，迁移到生产环境的Python、C、Java、Go等环境应用也大致如此。1、创建一个简单的
导言上一篇文章给大家梳理了DevOps持续交付体系出现的时代背景，以及其定义和解读，也引出了对IT价值流的理解。我们应该都可以感知到，对于新的体系在企业中的实际推广最难的不是体系本身，而是大家思想的抗拒与行动的惰怠；所以在引入推行过程中首先做的是对大家的“思想”松松土。!image.png(https://s2.51cto.com/images/20220903/1662172350914167.
导言：云原生技术生态除了上述篇章已经讲述的微服务架构、容器技术（Docker）、容器编排技术（Kubernetes）、ServiceMesh技术（Istio）等技术体系，还有一个很重要的管理实践——DevOps，在进行深层次的微服务或云原生应用架构改造后，进行对应的DevOps整体研发流程改造，可实现业务流程的自动化。下面我们就来了解一下DevOps这种产品研发管理实践。软件工程的发展“如何在满足
Istio 是 Service Mesh 实现中最成熟也最受欢迎的项目，由 Google、IBM 和 Lyft 开源。可以简单理解为： Istio 是一个用于服务治理的开放平台。 Istio 是一个 Service Mesh 形态的用于服务治理的开放平台。 Istio 是一个与 Kubernetes 紧密结合的适用于云原生场景的 Service Mesh 形态的用于服务治理的开放平台。
在复杂业务的后端服务开发中，拆分出的微服务往往是数十个、上百个，即使用上了容器技术方便了其打包部署，使用了 Kubernetes 进行便捷的容器编排管理，但众多微服务之间往往涉及到复杂的业务通信和服务治理场景。前面的篇章已经总体介绍了云原生技术体系中的‘微服务’、‘容器’、‘容器编排’技术，今天给大家介绍的便是体系中的服务治理方案‘Service Mesh（服务网格）’。
一、kubernetes基本介绍Kubernetes是Google开源的一个容器编排引擎，提供了⾯向应⽤的容器集群部署和管理。Kubernetes的⽬标旨在消除编排物理/虚拟计算，⽹络和存储基础设施的负担，并使应⽤程序运营商和开发⼈员完全将重点放在以容器为中⼼的原语上进⾏⾃助运营。Kubernetes也提供稳定、兼容的基础（平台），⽤于构建定制化的workflows和更⾼级的⾃动化任务。二、kub
导言：记得自己最早接触类似‘微服务’的理念和实践是在2013年写一个工业级IM系统，当时向往和学习的对象就是腾讯系。特别是腾讯大讲堂中一期《微信之道－至简》对自己的架构理念影响很深，比如下图（1）中体现的就是微服务的设计思想。我也是仿照此架构，设计了我们的IM系统架构。!image.png(https://s2.51cto.com/images/20220707/1657203021985196.
导言：至如今，云计算这个概念已经火了十年有余，我们这些相关IT从业者也经历了听闻、理解、应用、熟练这么个漫长的过程。当下，千行百业已从积极拥抱云计算向升级为云原生应用方向演进，特别在数字化时代的洪流中，云原生被视为未来社会数字化转型最有效的利器。我们则又要从理解云原生开始，将云原生应用在我们的工作中创造社会价值，也实现自我的价值。本文便将带大家通过“一图一文”全面了解云原生。一图一文Github：
导言：记得在远2012年时，因为向往着能写高并发程序，自己选择了跳槽。开始时是写支撑数万设备并发的程序（我们物联网设备业务需要保持长连接），随着企业的发展，逐渐增长到十万、数十万设备，当时还讲究挖掘单机性能，所以紧着各种线程模型、I/O模型……不断地挖掘潜能，实在挖不动了就开始着手用分布式方案的解决。比如当时开源的一个高性能服务模型：<https://github.com/yaocoder/HPN
导言：在自己从事产品研发实践和管理的十几年职业生涯里，少部分时间经历的是以瀑布式开发为主导的研发模式；绝大部分时间经历的是以敏捷开发为主导的研发模式；在硬件研发制造的场景下，也经历过以IPD（集成产品开发）为主导的研发模式。其实，各种研发体系的出现和行业实践，都是在解决“如何保障产品交付质量？”“如何提高产品交付速度？”的本质问题。同时，对于研发团队而言，不仅仅是按时保质的交付产品即可，如敏捷开发
曾以产研角色和企业管理者的身份亲自经历过PC互联网和移动互联网两段发展历程，现在面临新的一波AI浪潮时，联想起互联网对各个行业/企业的赋能甚至颠覆，十分笃定AI重塑行业/企业也一定是大势所趋。
导言：在自己从事产品研发实践和管理的十几年职业生涯里，经历过以瀑布式开发为主导的产品研发模式，经历过以敏捷开发为主导的产品研发模式，其相应的背景也是在软件项目和互联网软件平台为主导的情境下。但是当企业产品主要是硬件的研发、生产、销售时，经历的却是以IPD（集成产品开发）为主导的产品研发模式。其实自己经历过对IPD的抗拒，慢慢的适应，到着力推行的转变。作为一个软件开发工程师出身和大部分时间在做着互联
导读：《微服务设计》是一本非常出彩的技术书籍，从可读性、实战技术干货方面都非常优秀，甚至让我想起了曾经读《深入理解计算机系统》《UNIX编程艺术》这类经典好书时的感觉。以下是我做的一些概括性的读书笔记，非常希望大家能阅读全书，挖掘更多知识。
导言：记得在自己大学毕业的2006年到之后近五年的工作里，源于工作经历和有限的视野，几乎对“分布式系统”没有任何概念。当然，彼时的互联网/移动互联网还未对我们的生活呈覆盖颠覆之势，很多网络应用采用传统的集中式服务便可应对。但是随着互联网大潮的风起云涌，出现了越来越多的细分大流量网站及应用，网民体量也如滚落雪球一般越来越大，这种情况下分布式的概念几乎在技术圈“家喻户晓”，也成了我们追逐的另一颗时代“
导语：很久没写过涉及技术的文章了，因为进行职业转型后对技术有种很纠结的心态。热爱——每每看到五颜六色的代码窗口就会心里发酸，想起曾经那是生活中的一份灿烂心情；不自信——这么久离开技术会不会已经落后生疏（虽然一直没有脱离技术的学习与参与，但是失去了一线写代码的实践）。今天恰好去参加AWS（亚马逊云服务）的一个区域讨论会，一位亚马逊的架构师在为大家讲解AWS云服务及一些案例的架构设计，很多熟悉的概念，
导语：现在每当直接或间接带一支研发团队我都会给大家做一次敏捷思想和实践的培训（注：软件方向，复杂的硬件开发流程建议使用IPD思想）。作为一个有近10年的开发编码工作经验的资深程序员，作为一个管理者，作为一个还算转型成功的创业者，我一直有种初心希望所有研发人员能够敢于并且会表达自己，让更多的人了解自己；希望所有的研发人员不仅仅是机械的写代码，也能洞悉市场、了解用户，让自己的产出能够适配用户和市场的需
这些天恰好度过了自己的34岁生日，回头一算从06年工作至今已经有11年的职场经历，因为自己的专业背景，一直在技术型企业工作：经历过两家上市公司，一家集软硬件研发为一体的实业公司，一家自己参与创建和管理的互利网公司（集团子公司）。在总结了以上经历过企业的商业模式后，认为技术型企业通常有以下几种商业模式：卖人力资源，卖技术，卖产品，卖解决方案，卖服务、运营用户。卖人力资源：俗称软件外包，这类企业通过自
背景：标题起了这么一个悲戚戚的名字，自然后面承载着无数个“悲戚戚”的故事。我们平台业务中很重要的一块是视频直播服务（将幼儿园的视频直播给幼儿家长），由于我们没有使用土豪级BGP机房或云带宽网络服务，而是将视频服务器分布式部署在不同的运营商机房中，其中联通和电信多选择的是骨干节点，大家普遍反馈网络质量很好。移动网络就是就近（各省内）选择移动机房部署， 之前就常遇见移动固网用户投诉视频看不了，但还不是
自一年多没做技术以来，遇到一些技术同事离职或者参与平台的架构技术评审，每次都感觉困难，文档是其中一个重要原因，要么是随意写一份交接文档完事，要么就是简单画几副逻辑图来讲解评审，更多的是靠口诉。要说我们团队的这些技术人员个顶个也都算公司中的“高手”，但是我却觉得他们还欠缺一个真正的高手所需要的“一定要让别人清晰的、简单的理解你做的，所说的”。另外我们是如何了解历史的，我想就是因为很多人写下了历史，我
何为创业？为什么一开始就抛出这个问题。因为在“创业”这个词满天飞的今天，在政府对大众创业的倡导下，加之社会的鼓噪，创业仿佛成了一件人人可为之事，几乎每个咖啡馆都可以见到一拨拨的人在谈着自己的项目和梦想，每一个不分大小的创业大会总能吸引趋之若鹜的人群，社交网站上顶着总经理和CEO头衔的人越来越多。在我身边，刚参加工作不久的小同事，在职场遇到困境的老同事，天天想要创业的人也大有人在，但是问到他们想做什
写这篇文章时场景心境皆有不同，正在远离家乡北方遥远的南国深圳，也已经经历过了多次高密集度的各地出差和多个投资人的约见；盯着产品规划、深抠细节；也亲自跑过市场、谈过客户。对，我转型了，由一个对技术无比热爱的人，由一个封闭的技术人转型成为了一个为了公司存亡要想尽各种办法，要处理各种事情的所谓总经理或者CEO。这时我才发现创业维艰，这时我才发现原来技
背景：最近一直在给研发团队强调一定要把产品平台关键的账号系统分离出来，而不是和业务产品线有瓜葛。但是因为涉及改动太大，业务线很忙迟迟得到不到执行。在这种情况下，我协调召开了研发的紧急会议，要求务必在近期解决这个问题，甚至不惜减慢业务线的进度。其实如果大家仅仅是因为时间紧、任务重无法改动我倒不担心，我最怕的就是大家认为这件事情并不严重，在我做技术的9年生涯中见证过太多次因为不重视这种情况、或者推迟修
Copyright © 2005-2025 51CTO.COM 版权所有 京ICP证060544号
