会员中心
搜索
登录
注册

解决方案

数字化转型通用方案行业方案安全方案大数据人工智能物联网行业展望自动控制其他

产品|技术

白皮书产品介绍技术介绍技术创新模型算法

政策|规范

政策规范行动计划

电子书

电子书课件

报告|论文

报告模板论文

人工智能ArtificialIntelligence43

人类与机器最终都无法接受他，大卫只有唯一的一个伙伴机器泰迪（Teddy）----他的超级玩具泰迪熊，也是他的保护者大卫开始踏上了旅程，去寻找真正属于自己的地方。他发现在那个世界中，机器人和机器之间的差距是那么的巨天，又是那么的脆弱。他要找寻自我、探索人性，成为一个真正意义上的人。

  • 2021-06-28
  • 阅读179
  • 下载0
  • 43页
  • pdf

教育大数据及人工智能项目商业计划书

专为教育特点自动研发的教育大数据中台，集数据采集、治理、Al计算、存储、资产管理、数据安全于一体。可以解决学校数据自动化采集、信息孤岛问题。帮助学校利用数据、挖掘数据，分析问题，做到数据决策、精准教学。

  • 2021-06-28
  • 阅读163
  • 下载0
  • 17页
  • pdf

微服务架构实施原理详解

基于微服务架构和Docker容器技术的PaaS云平台建设目标是给我们的开发人员提供一套服务快速开发、部署、运维管理、持续开发持续集成的流程。平台提供基础设施、中间件、数据服务、云服务器等资源，开发人员只需要开发业务代码并提交到平台代码库，做一些必要的配置，系统会自动构建、部署，实现应用的敏捷开发、快速迭代。在系统架构上，PaaS云平台主要分为微服务架构、Docker容器技术、DevOps三部分，这篇文章重点介绍微服务架构的实施。

  • 2021-06-28
  • 阅读127
  • 下载0
  • 10页
  • docx

DDD兴起的原因以及与微服务的关系

我们先不讨论DDD的定义， 先梳理一下DDD火起来的背景， 根据我学习的套路， 永远是为什么为先，再是解决什么问题，是什么东西， 最后如何使用。我们都知道这些年随着设备以及技术的发展，软件架构发生了很多变化，从最初的单机（BS/CS）架构到后面的集中式架构，再到如今的微服务架构， 现在基本可以说是微服务架构盛行的时代， DDD早在2004年就由埃里克·埃文斯提出， 但一直处于一个不愠不火的状态，直到Martin Fowler的《Microservices》引起大家注意， 也就是微服务盛行之后（这儿需要说明的是，微服务最早的提出者不是Martin Fowler，而是Fred George）， DDD再次回到人们视野中间，为什么呢 ？

  • 2021-06-28
  • 阅读125
  • 下载0
  • 5页
  • docx

Redis基础、高级特性与性能调优

本文将从Redis的基本特性入手，通过讲述Redis的数据结构和主要命令对Redis的基本能力进行直观介绍。之后概览Redis提供的高级能力，并在部署、维护、性能调优等多个方面进行更深入的介绍和指导。

  • 2021-06-28
  • 阅读136
  • 下载0
  • 41页
  • docx

大型分布式Web系统的架构演进

网站的初期，我们经常会在单机上跑我们所有的程序和软件。此时我们使用一个容器，如Tomcat、Jetty、Jboss，然后直接使用JSP/Servlet技术，或者使用一些开源的框架如Maven + Spring + Struts + Hibernate、Maven + Spring + Spring MVC + Mybatis。最后再选择一个数据库管理系统来存储数据，如MySQL、SqlServer、Oracle，然后通过JDBC进行数据库的连接和操作。

  • 2021-06-28
  • 阅读244
  • 下载2
  • 28页
  • docx

基于 Kubernetes 的微服务项目设计与实现

随着互联网的发展，后端服务和容器编排技术的日益成熟，微服务成为了后端服务的首选，Kubernetes 也已经成为目前容器编排的事实标准, 微服务拥抱容器时代已经来临。笔者结合自己的经验，写了这篇微服务+ Kubernetes 入门宝典，希望能够抛砖引玉。能让大家了解 微服务和 Kubernetes 如何配合。上卷主要描述 微服务设计，项目实现，kubernetes 部署，微服务的部署 高可用和监控 这几个部分。下卷计划讨论服务化网格和数据持久化, 有状态服务，operator 这几部分。本文由我独立完成（ppmsn2005#gmail.com）如有任何错误，

  • 2021-06-28
  • 阅读151
  • 下载0
  • 53页
  • docx

架构与思维：设计容量，到底有多重要 ？

单位每年都会举行运动会，有一个2000m长跑的项目，大约每年报名人员为男选手40人，女选手20人，只有一条橡胶跑道。一次比赛10人齐跑，所以至少需要6场比赛。2000米的完成时间要求是20分钟，超过20分钟不计数，所以比赛耗时我们计算为20分钟，加上比赛前的动员组织，比赛后的清场，我们假定每场比赛耗时30分钟。现在我们预估下耗时：1、60人/10人每场 = 6场，至少需要举行6场2、总耗时 = 6场 * 0.5h = 3h所以每年把这个比赛安排在下午3点到6点，是最后一个比赛项目，晚上7点举行颁奖晚会。这个预估容量也算合理。但是今年比较特别，取消了4000米的长跑，所以2000米报名人员激增50人。时间还是下午3点到6点，这个就有问题了，最后为了保证晚会的正常进行，一半的人员的比赛时间推迟到另外一周的周末，搞得怨声四起，大骂举办的行政部门不讲武德。这个是我们单位真实的故事，这就是设计容量，当你的业务场景的容量发生了变化时候，没有预估到他的变化，以及变化可能产生的影响，没有按照这个影响及时的做调整（比如将比赛时间提前，拉长整个比赛的过程时间，或者增加比赛跑到，同时进行两场比赛），就会造成灾难。

  • 2021-06-28
  • 阅读120
  • 下载0
  • 4页
  • docx