mesh

目标 目标系统架构演变，单体-分布式-微服务-中台 微服务架构核心解决，横向对比1.0、2.0、3.0 践行微服务架构，全组件解读！ 也谈中台 单体架构Monolithic 单体应用时代：应用程序就是一个项目，在一个进程里面运行。 简单-省事儿 电商UI->（自营、秒杀、超市、生鲜、金融）->DB 弊端就是东西都堆在一起，不能满足大数据高并发的诉求，逻辑太多，很难升级。 业务演进推动技术的发展。 垂直拆分 垂直拆分，独立部署和维护，分而治之！ 优势： 1.独立开发、独立维护、独立演化； 2.更好的利用资源； 劣势： 1.进程间数据同步，分家时断不掉联系的，联系就麻烦了； 2.分布式的代价，使用数据库时对数据进行加锁，数据更新事务的问题； 3.代码重复问题，如支付、用户管理等问题； 分布式的第一要务就是不要使用分布式。 分布式服务 分布式：多个进程协作完成一件事儿，多进程抽取公用服务，分布式完成功能。 分布式代价很高。 例如，自营服务调用用户服务、支付服务、日志服务等，依次顺序调用，如果对应服务失败是否需要回退数据，以及对应数据的处理逻辑是如何处理的。 分布式事务、分布式锁、服务注册、服务发现、服务安全、服务治理等等，多个问题都需要解决。 新的问题，也是会被解决的，问题都被解决后，分布式就成了常规手段，轻松的用来高并发，而且都不仅仅于此，包括故意分拆满足扩展性。 微服务架构

作者 | 磊之 不愿沟通是固执，不会沟通是傻瓜，不敢沟通是奴隶。 ——德拉蒙德 工作中，你是否经常看到别人在会上谈笑风生、纵横捭阖，但自己却唯唯诺诺，不敢表达观点？即便鼓起勇气发言却不被重视，经常被人打断？生活中，你提出个很好的家庭规划，却没人支持你？规劝自己的亲友却被误会，最后以吵架收场？ 当你的朋友指出你的问题可能在“沟通”能力上时，你却轻蔑一笑：“沟通这么简单事情，我会不懂？” 要知道许多大师花了一辈子研究“沟通”，最终觉得自己只能驾驭一些类型的沟通。 互联网时代的信息媒介很发达，但非常碎片化，你可能听过很多道理，但未必有意识地组织过，人脑对于没有体系化的观点，总会选择性遗忘。 所以，关于沟通，你可能需要重新思考。 真理的世界如同泥泽地一般充满了陷阱。树立一个清晰的“概念”好比在这片泥泽地里打桩，树立一个“理论”好比在这些木桩上架桥。 PART 1：沟通的定义？ 街头的大妈们家长里短地唠嗑，能不能叫“沟通”？大学课堂上教授口若悬河，滔滔不绝地讲课，能不能叫沟通？ 沟通是“有目的的多向信息交流” 。大妈聊天漫无目的，最多是“多向信息交流”，不是“沟通”；教授讲解虽有目的，但如果没有与学生互动，则也不算是“沟通”。 “沟通的方式一定是谈话么”？不是，能交流信息即可，不拘泥于形式。沟通完全可以借助文字、图片、音乐......比如写信、发邮件，甚至眼神交流也算，宋词中“执手相看泪眼

Sidecar设计模式正在收到越来越多的关注和采用。作为Service Mesh的重要要素，Sidecar模式对于构建高度高度可伸缩、有弹性、安全且可便于监控的微服务架构系统至关重要。而Service Mesh也已经被证明，正在改变企业IT的“游戏规则”，它降低了与微服务架构相关的复杂性，并提供了负载平衡、服务发现、流量管理、电路中断、遥测、故障注入等功能特性。 什么是Sidecar模式？ Sidecar模式是一种将应用功能从应用本身剥离出来作为单独进程的方式。该模式允许我们向应用无侵入添加多种功能，避免了为满足第三方组件需求而向应用添加额外的配置代码。 就像边车加装在摩托车上一样，在软件架构中，sidecar附加到主应用，或者叫父应用上，以扩展/增强功能特性，同时Sidecar与主应用是松耦合的。 举个例子，假设现在有6个相互通信的微服务，每个微服务都需要具有可观察性、监控、日志记录、配置、断路器等功能，而所有这些功能都是在微服务中使用一些第三方库实现的。 这样一组服务的实际情况可能会非常复杂，增加了应用的整体复杂性，尤其是当每个微服务用不同的语言编写、使用不同的基于.net、Java、Python等语言的第三方库…… Sidecar模式的好处 通过将公用基础设施相关功能抽象到不同的层来降低微服务的代码复杂性 由于我们不需要在每个微服务中编写配置代码

作者 | 不瞋 阿里云高级技术专家 导读： 用户需求和云的发展两条线推动了云原生技术的兴起、发展和大规模应用。本文将主要讨论什么是云原生应用，构成云原生应用的要素是什么，什么是 Serverless 计算，以及 Serverless 如何简化技术复杂度，帮助用户应对快速变化的需求，实现弹性、高可用的服务，并通过具体的案例和场景进行说明。 如今，各行各业都在谈数字化转型，尤其是新零售、传媒、交通等行业。数字化的商业形态已经成为主流，逐渐替代了传统的商业形态。在另外一些行业里（如工业制造），虽然企业的商业形态并非以数字化的形式表现，但是在数字孪生理念下，充分利用数据科技进行生产运营优化也正在成为研究热点和行业共识。 企业进行数字化转型，从生产资料、生产关系、战略规划、增长曲线四个层面来看： 生产资料：数据成为最重要的生产资料，需求/风险随时变化，企业面临巨大的不确定性； 生产关系：数据为中心，非基于流程和规则的固定生产关系，网络效应令生产关系跨越时空限制，多连接方式催生新的业务和物种； 战略规划：基于数据决策，快速应对不确定的商业环境； 增长曲线：数字化技术带来触达海量用户的能力，可带来突破性的增长。 从云服务商的角度来看云的演进趋势，在 Cloud 1.0 时代，基础设施的云化是其主题，采用云托管模式，云上云下的应用保持兼容，传统的应用可以直接迁移到云上

作者简介：余军，PingCAP 解决方案事业部总经理。 对于金融企业来说，尤其是银行、证券、保险这些行业，在一个 IT 系统运行支撑业务的过程当中，考虑到硬件的故障、网络的故障，等一切可能会对业务产生影响的突发故障。那么，在过去漫长的 IT 发展的过程当中，大量的技术被应用在关于如何解决组件级的高可用，整个服务的容灾和灾备，包括如何保证整体业务的连续性。 在金融行业来说，数据库作为最核心的基础组件之一，要求它能够安全运行和保障数据安全，这是一个刚需。另外，数据库服务本身的高可用，是我们实现整个对外数据服务连续性的最重要的基石。在这些基础上，光有高可用还是不够的，我们需要考虑到机房级的、数据中心级的、站点级的灾难导致的对业务的影响。配套的容灾技术，以及对应事件的方案，应运而生。在过去的二、三十年里面，关于容灾和技术的技术手段、软件工具，包括各种各样的方案、管理方法，在不断的展现。 传统数据库支撑关键计算的高可用/容灾方案短板 回到传统的数据库领域，在过去至少三四十年的时间里，我们都是在使用集中式的数据库，比如大家非常熟悉的 Oracle、DB2 包括曾经很辉煌的 Sybase、Informix 等等。这些数据库都是以大家所熟知的“ IOE”的架构来实现数据服务的。 在这些技术体系下，在长期的技术发展过程当中，也有产生对应的高可用和容灾的方案，比如说大家非常熟悉的 Oracle RAC

最近在开发小程序，身心疲惫，原因是功能和app相同，我裂开了。 各种封装组件，各种写页面，不过有个好处是以前写的h5拿来改一下标签，基本上还是ok的，就剩下最后几个功能，其中就有一个VR全景功能。 移动端倒是好做，上次做了大概2天就搞定了，原理就是threejs用css3做图片的旋转，具体例子可以参照 https://threejs.org/examples/css3d_panorama.html 不过多描述，下面进入今天的主角：在微信小程序中使用threejs实现VR全景功能。 刚开始想到这个功能，我是拒绝的，这简直就是要了我的头发啊，没办法，谁叫我走上开发这条不归路呢，自己选的路，秃头也要走完。。 那就硬着头皮开始吧，先百度搜了一下在小程序中使用threejs，找到一篇比较干货的文章 https://developers.weixin.qq.com/community/develop/article/doc/00066c4b230b085051592292f5bc13 ，这篇文章作者把threejs给提炼出来了一个小程序版本， 照着他的demo先把canvas给搞出来先。然后再实现全景，怎么实现也是头疼的事情，怎么，我不会写，还不会改吗？ 先看看以前h5的实现方式，采用CSS3DRenderer来实现，问题来了，小程序里面不支持dom的createElement，那咋整嘛

1、导入资源 首先我们导入游戏需要的资源： 导入之后我们可以在项目中看到我们的塔防游戏的资源 2、烘焙场景，制作怪物移动路线 我们首先将Resource文件里面的主要的游戏场景EVE拖入到我们的主场景中 然后我们利用导航网格的方法来控制怪物的行进路线，禁用掉原路线WayPoint，然后对整个场景进行烘焙，将EVE设置为Static静态环境。 然后选择Window菜单AI里面的Navigation，然后选择Bake进行烘焙 然后我们拖入一个怪物Zombie_1到场景中，给怪物添加一个Nav Mesh Agent的组件让怪物按照烘焙出来的路进行移动 设置Nav Mesh Agent组件的属性，让他的半径和高度贴合怪物本身的大小，然后新建脚本，将脚本放置在怪物对象上，控制怪物进行移动。 这里我们设置了一个全局变量targetPos，就是怪物要移动的最终目标点，我们新建一个Gameobject，命名为TargetPos，放置到场景对象EVE中，并且我们将TargetPos移动到怪物1的脚本组件的targetPos变量上，这样就可以对之前目标位置进行赋值。 然后运行测试一下结果，我们可以看到怪物动起来了，朝着最终目标进行移动： 3、怪物孵化器及动画状态机的制作 我们现在实现了怪物的行走，那么现在只需要让怪物在刷怪点固定出现就可以了，新机哪一个Gameobject命名为Gamemanage

作者 | 禾易 在第十五届“开源中国开源世界”高峰论坛上，阿里云资深技术专家、etcd 创始人、CNCF TOC 李响荣获 2020 中国开源杰出人物贡献奖。恭喜李响！ 去年，全球顶级开源社区云原生计算基金会 CNCF 正式宣布其技术监督委员会席位改选结果。阿里云资深技术专家李响入选，成为该委员会有史以来首张中国面孔。 李响是 CoreOS 最早期的工程师之一，参与创建了 etcd、operator framework、rkt 等开源项目。而在开源社区中，李响作为 etcd 作者被开发者所熟知，etcd 是国际知名且被最为广泛使用的分布式一致性存储系统，被阿里巴巴、腾讯、华为、腾讯、微软、谷歌、VMWare 等企业在生产环境和客户产品中使用，用来解决分布式系统中重要元信息存储、管理和备份的问题，以及分布式系统组件一致性协调的问题。 在加入阿里云后，李响一直在推动云原生领域自动化运维相关理念、Operator 概念、OAM 标准的建立。Operator 给予开发和运维人员在云原生平台构建无状态和复杂应用运维的理论标准和实践基础，大幅度提高了云原生运维平台的覆盖度，在开源生态中涌现出了超过 500 个 Operator 具体实现，覆盖了几乎所有的主流云原生软件的运维，其中包含 RocketMQ、Kafka、ZooKeeper、Consul、Argo、Kubeflow 等

到底什么是微服务？ 总结起来可以分为以下四点： 服务拆分粒度更细。微服务可以说是更细维度的服务化,小到一个子模块,只要该模块依赖的资源与其他模块都没有关系,那么就可以拆分为一个微服务。 服务独立部署。每个微服务都严格遵循独立打包部署的准则, 互不影响。比如一台物理机上可以部署多个Docker实例,每个Docker实例可以部署一个微服务的代码。 服务独立维护。每个微服务都可以交由一个小团队甚至个人来开发、测试、发布和运维,并对整个生命周期负责。 服务治理能力要求高。因为拆分为微服务之后,服务的数量变多,因此需要有统一的服务治理平台,来对各个服务进行管理。 继续以前面举的微博系统为例,可以进一步对内容模块的功能进行拆分 ,比如内容模块又包含了feed模块、评论模块和个人页模块。通过微服务化,将这三个模块变成三个独立的服务,每个服务依赖各自的资源,并独立部署在不同的服务池中,可以由不同的开发人员进行维护。当评论服务需求变更时,只需要修改评论业务相关的代码,并独立上线发布；而feed服务和个人页服务不需要变更,也不会受到发布可能带来的变更影响。 由此可见,微服务化给服务的发布和部署，以及服务的保障带来了诸多好处。 这份手册将会从入门微服务、落地微服务、进阶微服务、展望微服务，这四个方面从入门到展望，系统的了解、学习微服务。 入门微服务 01.到底什么是微服务? 02.从单体应用走向服务化

Mesh网络架构 E104-BT10G/N蓝牙模块最大的优势在于可中继网络内的任意数据，任意模块都是中继，中继的同时也都可收到数据 接线方式 测试模块只需用到VCC、GND、TXD和RXD引脚，分别与USB-TTL的3V3、GND、RXD和TXD相连 将蓝牙模块连接至PC机 本次展示用到1个E104-BT10G(网关)和2个E104-BT10N(节点) 初始化蓝牙模块 打开3个串口调试助手，分别连接3个蓝牙模块，波特率115200，停止位1，数据位8，校验位：无 第一个是蓝牙网关，后面两个是蓝牙节点 如果没有串口调试助手， 点击这里下载 ：https://pan.baidu.com/s/1nbn0FzQZrdvQuq9kT-ROaw 提取码：disd 02 C0 15 设置节点不进入睡眠 03 C0 17 00 00表示不进入睡眠，也可设置成01-FF，表示串口停止工作后超时进入睡眠的时间，为了测试方便设置成永不进入睡眠 设备入网(网关指令) 02 C0 09 每发送指令 只能让一个设备入网 ，本次有两个节点设备，那么需要发送两次，发送后需要等待大概10秒才有回应，请耐心等待，从图中可以看出有两个设备入网成功 至此，Mesh网络已经搭建起来 获取设备主地址 02 C0 0 B 节点1的地址是05，节点2的地址是02，网关设备入网返回指令中可以看到02和05设备已入网