Hello World - 应用
type: channel
link: http://blog.38data.com/index.php/category/%E5%BA%94%E7%94%A8/
items: 第七届世界智能制造大会
items: 管理心得，不间断记录
items: 软件架构师应该知道的97件事之概括
items: 7大迹象，表明你的DevOps 做对了！
items: 软件外包思考 二 验收
items: 软件外包思考 一
items: 亲测推荐 2021 年 SaaS 技术栈：Docker、Django、Traefik 和 IntercoolerJS
items: 企业上云：选型，策略，架构，实践
items: 网易推出App内嵌即时消息服务“云信”

第七届世界智能制造大会
type: item
date: 2023-05-19T23:42:09+08:00

管理心得，不间断记录
type: item
date: 2022-09-18T18:17:00+08:00
description: 兼职管理1、响应时间 微信响应时间 超过5分钟 2次 中止合作2、培养能力 经验、工具3、收益高于预期4、工程师和质量关于裁员裁员名单是根据个人在公司工作期间对代码的贡献来制定和排名的。高效工作总结：0、必胜信心1、结果导向2、完成时间3、物理专注公司管理思路：互相投资、互相信任，非传统主雇关系1、培养人，把能力传授给下面的人2、放权3、分享机制小团队项目组基本管理：1、放手，新问题主动处理、老问题交给下属处理，借此制定标准处理问题流程化；2、榜样，有困难主动承担、有问题主动冲锋；3、让功让利，向上让功、向下让利；温和派领导人管理思路：1、立功，对公司有贡献；2、握权，能够影响员工收入组成40%、考核评分、项目奖金；3、守信，不轻易承诺、一旦承诺必须兑现；4、立标杆，培养典型员工进步并树立标杆；团队凝聚力1、身先士卒，带动员工积极性；2、知人善任，用人长处；3、勇于背锅；4、尊重、感谢，公约机制；提高员工工作效率1、责任到人；2、限定时间；3、确定标准；4、重复一次；5、检查机制；6、验收考核；老版轻松X成就感V想明白，布置下去1、会算账，不算公司赚多少钱、算员工能赚多少钱；2、会画饼，公司壮大时候做到位置、发展前景；3、会激发，你是专家我不行、顶梁柱；

软件架构师应该知道的97件事之概括
type: item
date: 2022-05-15T21:49:00+08:00
description: 架构师是一种神秘的职位，据说每个架构师都有密不可传的方法，当然我们不信，更多的是只可意会不可言传。就是说了我们也不会懂，因为还每到“火候”。所能做的就是，当我们到这种火候的时候我们能想起来曾经有过架构师这么说过，然后我们就可以更自信的向前大步走....1、客户需求重于个人简历要想拥有漂亮的个人简历：我们常常向客户推荐技术、手段，甚至方法论来解决问题，使用时髦的编程技巧和流行的范式，有时候根本不是寻求解决问题的最佳方案。积累一批满意的客户，选择切合实际的技术解决他们的难题，让他们乐于推荐你才是最好的履历。2、简化根本复杂性，消除偶发复杂性根本复杂性指的是与生俱来的、无法避免的困难。比如，协调全国的空中交通就是一个“天生的”复杂问题，必须实时跟踪每架飞机的位置。偶发复杂性：是人们解决根本复杂性的过程中衍生的。架构师的责任在于解决问题的根本复杂性，同时避免引入偶发复杂性。怎么做？尽量选择源自实际项目的框架，警惕那些象牙塔里面的产品。3、关键问题可能不是出在技术上简单的项目也会翻船，而且这不是个别情况。大多数项目是人完成的，人才是项目成败与否的基础。如果团队里有人工作方式不正确，拖项目后腿怎么办？有一种非常古老但很完善的技术可以帮助你解决问题。它可能是人类历史上最重要的技术创新，这就是对话。有几个简单的对话技巧可以显著改善对话效果：不要把对话当成对抗。不要带着情绪与人沟通。尝试通过沟通设置共同的目标。4、以沟通为中心，坚持简明清晰的表达方式和开明的领导风格沟通必须简明清晰，没有人愿意阅读冗长的架构决策文档，架构师言简意赅的表达观点是项目成功的必要条件。架构师往往忽略了自己也是领导者。作为领导者我们必须获得同伴的尊敬才能顺利开展工作。所有的成员都希望有明确的沟通和开明的领导。只能这样才能改善沟通效果，建立团结健康的工作环境。5、架构决定性能大家似乎理解，事实并未如此，有些架构师认为简单的更换底层架构就足以解决应用的性能问题，他们很可能轻信了“经测试产品性能超出竞争对手25%”，比如从4ms到3ms，这1ms放在一个性能极低的架构里几乎可以忽略不计。归根结底，所有产品和架构必须遵循分布式计算和物理学的基本原理：运行应用和产品的计算机性能有限，通过物理连接和逻辑协议实现的通信必然有延时。因此，应该承认架构才是影响应用性能和可伸缩性的决定因素。性能参数是无法简单的通过更换软件，或者“调优”底层软件架构来改善的，我们必须在架构的设计和重新设计上投入更多的精力。6、分析客户需求背后的意义顾客和最终用户通常提出的所谓需求，只是他们心目中可行的解决方案，并不是问题唯一的解决途径，当了解顾客的需求背后的意义，我们可以为顾客解决真正的问题并可能降低难度。7、起立发言许多架构师都是从技术岗位上成长起来的，他们擅长和机器打交道，然而架构师更需要与人打交道，无论劝说开发人员接受具体的设计模式，还是向管理层解释购买中间件的利弊，沟通都是达成目标的核心技能。有经验的架构师会很重视推销自己的想法也明白有效沟通的重要性，其中一个简单又实用的技巧是在2人以上的场合发表意见时请“站起来”，起立发言非常重要尤其是当其他人坐着的时候。当你站起来的时候无形中添加一种权威和自信，自然就控制住了场面，听众不会随意打断你的发言，这些都会让你的发言效果大为改观，你会发现站立可以更好的用双手和肢体语言。在10人以上的场合，起立发言方便你与每位听众保持视线接触。眼神交流、肢体语言等表达方式在沟通中的作用不可小觑。起立发言还可以让你更好的控制语气、语调、语速和嗓门，让你的声音传的更远。当你讲到重点内容时，注意放慢语速。发声技巧也能显著改善沟通效果。比沟通事半功倍，起立发言是最简单、有效的方法。8、故障终究会发生硬件会出错，于是我们增加冗余资源来提升系统的可靠性，同时也增加了至少有一台设备出错的概率。软件会出错，增加额外的监控程序也会出错。于是我们又为自动化增加监控，结果是更多的软件，导致更高的故障率。类似的如：三里岛核电站泄漏事故既然必然会出错就需要事先设计好防范故障的模型，以应对威胁系统安全的意外情况。9、我们常常忽略自己在谈判我们都面临过削减预算的要求，如果资金运转促襟见肘，技术方案只能委屈求全。比如如下情景：“我们真的需要这东西吗？”项目投资人发难道。尽管真的需要，我们通常也不能这么回答，因为此时我们是在谈判，此时我们需要认清自己的角色，不能把自己当成工程师，而且投资人明白他在和你谈判，我们应该这样回答"真的需要吗"这类问题：“单台服务器每天至少崩溃3次，没有第二台我们甚至无法跟董事会演示，事实上我们需要4台服务器，构成2组，这样在需要时断开一组而不必被迫关闭系统。即使有一台出现意外，也不影响系统正常运行”10、量化需求速度快不能算作需求，响应灵敏和可扩展也不能算需求，因为我们无法客观…

7大迹象，表明你的DevOps 做对了！
type: item
date: 2022-03-08T16:20:15+08:00
description: 据预测，未来 10 年中，企业或组织的数字化转型会达到高峰，将比过去几十年的总和还要多。而这一进程，开发工程师必须找到更加有效的开发方式，才能实现。在这一层面来说，DevOps 是数字业务转型计划的核心。目前，企业越来越重视DevOps，并开始向这种开发方式转型。但是，如此多声称专注于 DevOps 的企业或组织，真的都做对了吗？在大多数的 DevOps 实践中，仅仅涉及到了特定工具的使用，企业非常松散地遵循着某些 DevOps 原则。然而，要想真正成为一个以 DevOps 为中心的组织，这些远远不够。参照以下 7 点，或许能够帮助你及时纠偏：一、部署是完全自动化的每一个项目工程通常都包含了很多的代码文件、配置文件、第三方文件、图片、样式文件等不同部分，要想将这些部分有效组装、最终形成最后的应用结果，往往需要借助构建工具或策略。构建过程如果仅仅依赖人工，就会十分繁琐。于是，自动化构建、自动化发布、自动化部署的想法和探索就浮现了。自动化的出现，将大大提升工作效率。在 DevOps 实践中，是需要从头到尾完全自动化部署的。自动部署的意义不仅仅在于节省时间，更多是避免问题的出现，手动部署更常出现因为人为错误引起的问题，而自动部署可以在问题出现时迅速恢复到以前的版本。二、有频繁且快速的发布周期天下武功唯快不破。想要获得更强大的竞争力，只有不断部署和快速修复。DevOps 中一个核心功能就是 CI/CD（持续集成/持续交付），寻找更有效的自动化和部署更新迭代的方法，让开发人员提高生产效率、并快速地发布到生产环境中。CI/CD 通过在构建、测试和部署应用程序时强制自动化完成。这种 DevOps 方法的精髓在于：1）通过频繁的代码库提交、自动化构建等来提高生产力；2）通过集成自动化测试以及开发期间的测试，增加在开发早期发现错误的机会；3）得益于频繁的测试和自动化部署系统，可以更快地发布版本。三、注重可观察性国外的一份报告显示，可观察性正在成为 DevOps 实践中绝对不能缺少的一环。在跨越多个流程的数字业务转型中，可观察性有非常重要的意义。New Relic 对 1300 名 IT 领导者、软件工程师和开发人员进行的一项全球调查发现，90% 的受访者认为可观察性对业务至关重要。只有更多地基于事实而非直觉，才能作出明智的决策，越来越多的团队开始从整个企业应用程序环境中收集数据，来提高整个开发过程的可观察性，可观察性也在生产前和生产后的环境中扮演越来越重要的角色。四、有持续的反馈循环初期，DevOpsDays 活动的发起人和 DevOps 这个词的创始人 Patrick Debois 发现，有关 DevOps 的话题相互交织在一起形成了四个不同的反馈环，如上图所示。其中，蓝色气泡代表技术，黄色气泡代表过程管理。一起形成了 4 个循环。开发-测试反馈环（黑色箭头反馈环）；开发-运维反馈环（绿色箭头反馈环）；业务-运维反馈环（红色箭头反馈环）；业务-用户反馈环（紫色箭头反馈环）。在现在的 DevOps 理念中，出现错误并不可怕，可怕的是没有一个持续的反馈循环系统来检测何时何地出现问题。反馈循环需要在发生错误时快速通知，从而使问题得到更快地解决。很多时候，我们遇到问题仅仅是简单地解决了它，并没有花时间分析问题发生的原因以及如何防止问题再次出现。这样的循环是不完整的。从某种程度上，如果你设置了一个系统来识别问题、修复问题和改进问题，还需要认真分析，才意味着你在正确地实践 DevOps。具体来说，一个监控系统需要观察并记录系统状态变化和数据的流程：1）状态的变化：可以通过状态的直接度量或者更新日志来表示；2）数据：可以通过记录内部组件和外部系统之间的请求和响应来记录。五、开发和运营团队一起工作Dev（开发） 和 Ops（运维） 的矛盾主要是面向适应性的敏捷软件交付和面向经验性的传统运维之间的矛盾。这个矛盾最先由 John Allspaw 和 Paul Hammond 在“10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”提出，并以“Cooperation”作为整个演讲的核心，讲述了他们解决这个矛盾的实践经验。在一个组织中，如果相关利益者的利益不一致，在既定流程的进行中一定会碰到诸多阻力。而在这一点上，首先做的就是把 Dev 和 Ops 的利益一致化，从而减少 Ops 对软件交付的阻力。在传统观念中，开发的工作是增添新的功能，而运维的工作则是保证站点的稳定和高性能。 而在 DevOps 的观念中，Ops 的工作目标应该是激活业务（enable the business ），与 Dev 是一致的。至此，DevOps 众所周知的主要好处就是打破开发和运营之间的孤岛。在维基百科上，DevOps 的解释也…

软件外包思考 二 验收
type: item
date: 2021-07-20T09:27:00+08:00
description: 交付物软件100%实现需求明细列表所有功能，即100%满足业务需求的软件。文档项目验收验收方式1、将要交付的软件安装于指定服务器，并完成调试和上线；2、完成培训后，业务验收人员根据需求明细列表实现情况进行验收评价，研发验收人员根据以下内容进行验收评价。文档验收1、文档齐全（参考如上文档清单）；2、文档内容描述准确, 没有歧义和错误的表达；3、文档内容容易理解, 通过使用适当的术语、图形表示、详细的解释来表达；4、文档对主要功能和关键操作尽量提供应用实例。界面验收1、界面设计符合自己公司的设计规范；2、外包团队需提供与软件适配的浏览器、手机、PAD等品牌与版本号清单；3、各界面需要做好PC、手机、PAD等UI兼容与机器适配；4、原则上，浏览器至少需适配Chrome、Safari、火狐、IE8以上；5、原则上，手机至少需适配苹果、小米、华为、vivo、OPPO、三星、魅族。功能验收1、功能验收范围覆盖（接口、数据库存取、页面功能）；2、提供单元测试用例、集成测试用例和系统测试用例；3、提供BUG管理跟踪记录表；4、提供质量分析报告。性能验收1、提供性能测试报告；2、相关重要指标达到以下要求：安全验收1、软件中的敏感数据需以密文方式存储；2、软件需有留痕功能，即保存用户的操作日志、系统异常日志、接口调用数据日志等；3、软件中各种用户的权限分配合理；4、扫描出的安全漏洞（包含但不限于：越权访问、XSS跨站攻击、SQL注入、文件上传漏洞、跨站请求伪造等）外包团队需修复完毕。用户验收1、外包团队需提供稳定的用户验收环境和联调环境；2、业务场景功能测试不通过数的比例<1.5%；3、不存在严重等级为1的错误；4、不存在严重等级为2的错误；5、严重等级为3的错误数量≤5；6、所有提交的问题都已得到修复；7、以上功能，用户验收测试通过后，由用户负责人签署验收通过确认书。源码交接如涉及到源码交接，按下列规范进行验收和交接。交接前提条件1、需提供用户验收通过确认书；2、涉及交接的软件，原则上建议接受交接软件所有功能，不建议交接软件部分功能模块；3、跟薪资类无关的软件或功能，所有功能需在线上稳定运行不少于3个月；跟薪资类相关的软件或功能，所有功能需在线上稳定运行不少于6个月；4、线上稳定运行既线上可用率，需满足：最近3至6个月内，线上没有出现影响20人以上或数据错误的严重bug，且每月线上bug数不超过3个。源码验收1、代码应只保留跟本项目相关的代码，无效代码应一律去除；2、数据库应只保留跟本项目相关的表、视图、存储过程、函数、触发器、定时job等，无效内容应一律去除；3、特别注意合理做好数据表结构设计，适当冗余提升性能；4、代码结构清晰无冗余，注释完整有效，避免硬编码；5、但凡不符合源码验收规范的，外包团队需修复完毕。其他注意点1、对于外包团队的软硬件选型，建议业务部门邀请本公司IT团队一起参与决策；2、与外包团队商签署的商务合同和补充协议等，建议业务部门邀请本公司IT团队一起参与制定；3、外包团队使用的环境、数据库、网络、语言、框架、技术、组件等需事先获得本公司IT团队认可；4、如外包项目不符合或无法满足上述验收规范的，建议商务层面延长付款周期、扣除相应款项或终止合同；5、每一笔合同款在支付给外包团队之前，除了需获得用户验收通过确认书之外，还应通过IT团队验收；6、以上内容建议附加进商务合同，成为其中一部分。

软件外包思考 一
type: item
date: 2021-07-04T22:26:00+08:00
description: 软件外包存在风险，外包人员技术、态度、交付能力，如果想通过合同或者诉讼降低风险，由于太多的未知因素和太多的主观性，不现实。因此唯一的外包原则应该是：如果外包人员做得不好，有能力随时终止合作且可控费用损失和项目交付。可以尝试渐进式方法，首先废除传统开发外包大瀑布方式（例如签订需求URS、项目总金额、进度款支付）（不过目前大部分外包会坚持使用瀑布法，并签订大额的预付合同），尝试新方案，项目按照功能或者阶段划分为多个子合同，做小项分包，或者改为签订人力外包合同。针对我们想要构建的功能，拟定一个顺序列表。找几名开发人员，最好是独立的自由职业者，但如果同意以下流程，开发工作室也没问题。对于每名开发人员，挑选列表中最重要的功能，与他们讨论功能需求、预算和成本。让他们实现那个特性并测试。让一名内部人员审核他们的 PR，测试升级后的 App，并标出有问题的地方。符合要求后，合并并部署该特性，这样，所有创始人/用户就可以继续审核该 App，并提供反馈或者根据需要调整。如果我们对他们所做的工作感到满意，就挑选下一个我们希望他们实现的功能，然后再次重复这个过程。如果我们对他们的工作不满意，就解雇他们，并寻找替代者。当前需要做的工作，整理敏捷开发平台或者公共开发平台，并且参照以下原则：客户合作胜于合同谈判个体和互动胜于流程可运行的软件胜于详细的文档响应变化胜于遵循计划参考文章：Experiences working with an Outsourced Dev Shop

亲测推荐 2021 年 SaaS 技术栈：Docker、Django、Traefik 和 IntercoolerJS
type: item
date: 2021-03-14T23:29:00+08:00
description: 我最近发布了个人对Django做为一款优秀应用框架的一些考虑。本文基于此从架构角度做进一步扩展，介绍从开发到生产环境的整体技术栈考虑。2018 年至今，我一直使用该技术栈构建一些小型 SaaS 应用。本文最初发布于 www.simplecto.com，经原作者授权，由 InfoQ 翻译并分享。整体技术栈随处部署的 Linux 服务器和虚拟机：我使用了 Azure、Digital Ocean 和 Scaleway，并计划在 2021 年将所有部署迁移到Hetzner提供的专用服务器上。Docker：就是我们常用的 Docker.Traefik：使用 LetsEncrypt 证书的反向代理和 TLS。Postgresql：运行在 Docker 中的数据库。Django：同样运行在容器中。IntercoolerJS：提供平滑易用的类 Ajax 前端应用支持。Intercooler 的创作者在 2021 年发布了HTMX，是 IntercoolerJS 的更新换代。Sentry：捕获生产环境中软件缺陷。只需在配置文件中添加几行配置。Bitbucket Pipelines 替代 CI/CD：鉴于 CI/CD 引入了过多繁琐无用的工具，我在 2021 年不再对个人项目考虑 CI/CD。ZeroTier：实现 VPN 和控制层。我在开发小型项目时，采用本地 Docker 容器运行测试，进而直接推送到生产环境。我不考虑使用繁琐的 CI/CD，而是选择了 Bitbucket Pipelines。上图给出了我所采用技术栈的概览，图中有很多需要详细展开阐述的部分。下面换成列表方式展示。虚拟机DockerDjango挂载数据磁盘卷使用长时间运行 Django 命令做为 Workers挂载数据磁盘卷Postgres挂载数据磁盘卷TraefikZero-TierSSH托管环境即便是无服务器架构，也需要一个云服务托管环境。我个人推荐Azure、Digital Ocean和Scaleway。每家都为计算、联网、存储和基本服务提供了充分的选项，支持用户任何构建需求。同样推荐Hetzner，它提供了各服务层级的硬件、服务和价格。虚拟机一些企业应用和个人副业（side projects），并不需要同时为成千上万的用户提供 TB 级数据服务，因此可扩展性并非主要关注问题。对于此，我们可选用最小托管服务选项，通常不高于每月 20 美元。即便是服务价格相对最贵的 Azure，也可选用 Burstable 服务质量的虚拟机。个人推荐Scaleway的开发层级服务器。注意：在我的技术栈中并没有 Kubernetes，因为我并未考虑可扩展性。Docker为确保新的虚拟机运行在最新版 Docker 上，我并没有依赖操作系统本身，而是使用了 curl|bash 方式，即：curl -s https://get.docker.com | sudo bash 运行上面一行命令，就能获取最适用于当前运行环境的最新版本。Traefik 实现反向代理Traefik 对我简直是天赐之选。尽管 Nginx 也很强大，但其并非针对 Docker 环境构建。Traefik 的两个杀手级特性，为我节省了大量时间：使用 LetsEncrypt 实现自动 TLS。简而言之，一旦设置，无需操心。结合适用的 API 和 DNS 服务提供商，还可以使用 DNS 验证。使用 Docker label 实现无需重新加载的自动配置。一旦新服务发布，Traefik 通过监听所有 Docker 相关服务而自动发现更改。这使得服务的添加、移除和合并非常方便，不存在任何麻烦。我对 Traefik 唯一意见是学习曲线略为陡峭。用户必须自行确定如何进行配置，包括配置文件、命令行选项、YAML、Docker label，乃至组合使用。提示：我发布了自己使用的Traefik生产环境配置文件，供参考。Postgres 数据库亲测推荐，PostgreSQL 从不会令我失望。PostgreSQL 容器可毫无问题地添加到任何项目中。我只需简单地启动容器，绑定端口，挂接数据卷到主机磁盘，仅此足矣。docker-compose.yml version: '3.1' services: db: container_name: postgres hostname: postgres image: postgres:11 restart: always environment: POSTGRES_PASSWORD: secretsonly volumes: - ./data:/var/lib/postgresql/data ports: - 5432:5432 networks: - web networks: web: external: tr …

企业上云：选型，策略，架构，实践
type: item
date: 2019-06-22T02:50:56+08:00
description: 1概述2018年8月，工业和信息化部印发《推动企业上云实施指南（2018-2020年）》，提出到2020年行业企业上云意识和积极性明显提高，上云比例和应用深度显著提升，云计算在企业生产、经营、管理中的应用广泛普及，全国新增上云企业100万家，形成典型标杆应用案例100个以上，形成一批有影响力、带动力的云平台和企业上云体验中心。鼓励各地加快推动开展云上创新创业，支持各类企业和创业者以云计算平台为基础，利用大数据、物联网、人工智能、区块链等新技术，积极培育新业态、新模式。随着云计算的蓬勃发展，各个企业开始纷纷入云，但是在入云的道路上各自不同，根据企业的规模、技术特点、保密性的要求等，可选择的有公有云、私有云、行业云、混合云、集团云等等。本文主要讲企业在上云的过程中的一些要点，从为什么要上云、怎么上云、都有哪些考虑点、云上有什么样的技术，最后提供了上云实践的必要过程。2为什么要上云？企业的基础架构从传统的烟囱式部署专项云端部署，基于云计算平台的解决方案，已经成为企业管理者满足其业务战略的需求，快速实现其收益和效率的最聪明和最无缝的方式。云计算服务为公司提供了巨大的优势和工作量转移：IT部门不再需要购买、部署和维护内部的计算硬件和软件，可以通过云服务快速、容易地建立起来，无需IT人员参与就能根据需要进行扩展，并且会自动更新到最新版本。简而言之，云计算极大地简化和降低了IT服务提供的复杂性和成本。数字经济已经成为发展趋势，各企业都在进行或准备进行数字化转型，而上云则是企业数字化转型的起点。企业上云，主要有以下几点原因：■ 降低成本。企业运营需要成本，IT基础设施投入也是成本，大企业为了降低成本，提高集约化效果，形成企业内部或者集团内部的私有云、集团云；中小企业为了降低成本，选择公有云或者行业云、混合云；微型企业，无需投入建设机房、购买IT设备的资金，直接用公有云服务商提供的公有云服务。使用云计算服务，比购买一般的物理硬件要便宜得多，那么小微企业就可以摆脱很多不必要的开支。■ 高效弹性，灵活扩展。满足弹性、快速供给、快速释放的IT基础设施能力，才能更好的为业务服务。效率是企业的生命线，只有提高了生产率，企业才能在市场竞争中生存，云是提高IT基础设施效率的非常好的手段。■ 使云端数据更有价值。云带来了更大的灵活性和移动性，使用云，可以让企业在一台机器上开始工作并且在另外一台机器上完成它；企业对于庞大的交易、管理等数据做大数据分析，提供精准营销、分级客户管理等服务，使数据增值；人工智能更是基于大数据为基础，提供更加高阶的场景化服务。■ IT部门从成本中心转向利润中心。云的未来，不是一个成本中心，而是一个利润中心，它能创新很多新的业务模式，成为企业新的利润增长点。3上云的难点分析大中型企业的IT基础设施，一般都有比较重的历史包袱，如应用系统为部门级而非企业级、数据割裂且格式不统一、烟囱式部署架构、无法按需扩展等等，因此企业上云，主要有以下几个难点：■ 云化架构转型，需要建立相应的组织架构及人才队伍。从上层管理层到中层及下层技术人员，都要首先从意识形态上接收并主动拥抱云，理解云的架构、云的特点，建立起适合云计算发展的组织架构，培养响应的人才队伍，才能更好的做云化转型；■ 原有的IT架构，难以向云端迁移。云大多以虚拟化、开源技术、分布式技术为主，而原有的大多使用了大型机或小型机、相对重量级的中间件和数据库、以闭源厂商的产品为准，因此无法把现有的系统直接搬上云，必须要做云化改造；■ 原有系统复杂，系统需要重构。由于历史的原因所建立的系统必须要做重构，采用云化架构，使用适合云部署的技术，如虚拟化、容器化、微服务化，同时基础设施要建立相应的计算、网络、存储等资源池，采用计算虚拟化、软件定义存储SDS、软件定义网络SDN等技术、容器Docker等技术，提供IAAS、PAAS、SAAS、CAAS等云服务。4上云的方向选择企业上云，根据自身的特点，选择上云的方向，既要满足监管的要求、企业的需求，也要考虑自身能力，切不可能盲目跟风，选择与自身实力不匹配的方向，可以从以下几点考虑：■ 大中型企业。这类企业自身盈利能力较强，抗风险能力较高，IT基础设施投入较大，一般都会选择自建私有云，同时会考虑输出部分云计算能力给其他中小微企业使用，如某国有银行，不但建有内部使用的私有云，还有为集团、分行、子公司及外部客户使用的公有云，通过建信金融科技公司，提供从上到下的IAAS、PAAS、SAAS全套金融云服务；■ 小型企业。这类企业因自身规模没有大中型企业大，IT基础设施投入相对要小，可以选择混合云或者行业云，自身因为数据保密的要求，将核心关键的系统建立在私有云中，对于不关键的系统可以使用公有云或行业云，以此降低IT投入成本。■ 微型企业。这类企业对于成本比较敏感，IT投入比较…

网易推出App内嵌即时消息服务“云信”
type: item
date: 2015-10-28T02:34:00+08:00
description: 网易将于 13 日正式发布基于 PAAS 的 IM 云服务“云信”。开发者可以通过客户端 SDK 和云端 REST API 让自己的应用快速轻松接入聊天功能。据介绍，网易新闻客户端的跟帖与私信功能采用的就是和“云信”一致的技术平台。网易表示，云信的背后是网易 POPO 和网易即时通等产品积累的长达 15 年的即时通讯开发经验。产品优势在于可以为开发者提供更成熟的样本经验、更丰富性的模式选择、更稳定的CDN服务（多节点）。官方资料称，网易拥有“业内最大”的服务集群架构，已成功发送1000亿条消息。经第三方权威测试，每日上亿条消息100%到达。基于POPO的私有精简二进制协议，可以提供更快的速度和更好的性能。对接入后的开发者，云信将提供7*24小时实时运维监控，技术工程师全天候响应，定期开展免费培训课程和技术沙龙。网易自己的网易新闻、网易云音乐、网易云课堂、网易花田等APP、以及顺丰快递、传化物流、家校无忧、企业书屋、上海清算所等单位都已经应用了云信的服务。网易云信