3 申请微信小程序和微信公众号

于 2025-02-07 15:19:27 发布
阅读量285 收藏
点赞数 7
CC 4.0 BY-SA版权
文章标签： 微信小程序 微信 小程序
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/yusongcao/article/details/145495883

申请小程序
百度搜索微信公众号，如下图所示:
在这里插入图片描述

我们找的标有官网的标题点击进去。如下图所示:
在这里插入图片描述

如果已经有小程序，点击扫码登录自己需要登录的小程序即可。如果没有注册过，点击下方的三个选项选择你要做的帐号类型。
注册成功后绑定微信，以后扫码登录即可

博客
爱书爱考平台说明
01-28 716
后面我也会带着大家开发一套微信小程序，包括上架、运维、部署环境的搭建、相关资质的审核等一系列开发和上架的过程都会记录下来分享给大家。最近我开发了一个综合性的考试平台，内容包括但不限于职业资格证考试、成人教育、国家公务员考试等内容。目前1.0版本已经开发完成，其他的功能陆续完善中。目前维护了java相关的面试题的考题和详解信息。你的关注是我最大的动力。
博客
2 注册公司并准备相关材料
02-05 831
点击进入给我们的域名填写备案信息并提交阿里云审核，阿里云审核通过后会给你打电话确认信息，然后提交到当地的备案管局审核。我们可以到阿里云的官网上选择购买域名，用户首次购买域名1年只要1元，后面费用会增加。我的域名是aishu.icu首年费用是1元，后续一年的费用是63元。我注册公司的时候没有自己去跑，找的代注册公司帮注册的几百块钱。说说注册公司需要准备的材料，如果找注册公司代办，代办人员会和你讲清楚。先属于自己想要的域名，点击查询，选好要购买的域名。我们在这个页面可以管理我们的域名，配置映射的ip信息等。
博客
1 项目概述
02-03 377
先带着大家做一个无限极返佣的系统和一些赚外快的小项目和一些游戏脚本(主要是按键精灵和C++开发)还有一些爬虫项目，这些项目都是能够给大家带来收益的，创作不易，这些项目可能都要收费才能看。然后做一个基于分布式的通用功能，方便以后快速开发项目。项目篇带着大家一起做项目，其中涉及到产品设计，架构设计和前段后端的开发工作。带着大家一起把项目做起来。开始我们做几个小项目，基本涉及不到架构设计。后面再做涉及到我们前面讲到的架构设计的相关知识，把能用到的技术大体上用一遍。后期还会分享一些我赚外快的一些项目。
博客
19 压测和常用的接口优化方案
01-31 544
压测的测试报告主要有以下几个方面:1.响应时间 2.不同的线程压测的错误率,也叫失败率3.吞吐率(TPS)4压测情况下服务器的其他性能指标。如:网络层、代理(nginx)、CPU、缓存中间件的指标等。这些需要看具体的项目需求。专业的测试使用loadrunner测试的结果非常全面，也可以根据具体的业务写脚本测试。一般的排查资源释放问题，一些性能指标使用jmeter即可。高并发的平台应用，项目上线前离不开一个重要步骤就是压测，压测对于编码中的资源是否问题的排查，性能的调优都是离不开的。
博客
18 大量数据的异步查询方案
01-30 342
我们知道在数据库中的模糊查询需要全盘扫描，找的匹配的字符并返回，性能上就会比较慢，特别是数据量比较大的时候就是一个灾难。通过分词映射到实际数据的方式避免全盘扫描的问题，如果是海量数据，es的存储压力比较大，那么我们把海量数据存储在分析型数据库中即可。主流的两种hbase和clickhouse，千亿条数据查询也是很快的，但是分析型数据库对修改的操作性能非常差，我们使用的时候注意这一点就可以了。我们在java程序中查询的时候通过es的分词找的数据实体，然后需要找全量数据的时候再到分析型数据库中查询即可。
博客
17 一个高并发的系统架构如何设计
01-27 1368
我们分库还有一个原则就是一个数据库实例操作数据的瓶颈受到数据库引擎程序执行的瓶颈影响，所以在高并发的环境下，做好了垂直拆分的数据库，如果一个数据库实例承载不了并发的情况下，我们也要做水平拆分，一般会根据主键hash求模或数值型主键求模做水平拆分。我们的系统在做一些活动的时候，会产生一些瞬时的高峰流量，这些请求如果直接和数据库交互处理业务的时候会把数据库压垮。第三:高并发系统常见的需要考虑的问题，如内存不足的问题，服务抖动的问题、磁盘不足的问题、网络带宽的问题、突发流量的问题、面对黑客攻击的问题。
博客
16 分布式session和无状态的会话
01-25 1100
如果以集群的方式部署，用户登录的session存储在该次登录的服务器节点上，如果下次访问服务端的请求落到其他节点上就需要重新生成session，这样用户需要频繁的登录。该方案缺乏容错性，如果用户请求的机器发生故障，请求就会落到其他的节点上，session就会失效。使用中间件存储session信息。当nginx使用该方式代理请求转发时，相同ip的用户请求会落到相同的机器上，这样就可以避免了频繁的登录。该方案保证了容错性，如果在用户量很大的情况下网络会成为同步的瓶颈，整个集群的性能会受到严重的影响。
博客
15 分布式锁和分布式session
01-23 1271
当某个进程想要做唯一资源操作时，插入数据表示获得锁，并获得该资源的使用权，其他进程想要获取该资源的使用权时，发现数据库中已经有记录了，就需要等待。我们一个进程想要获取锁，在进程中生成uuid(保证唯一性即可)放入redis中，其他进程想要获得锁资源先判断本进程的uuid是否和redis中的uudi匹配，不匹配说明不能进行资源的操作。会话超时:如果一个子节点的会话超时了，因为创建的是临时节点，因此对应的临时节点也会被删除，这样避免了死锁的出现。永久节点不会因为会话的结束而消失，临时节点随着会话的结束而结束。
博客
14 常用的负载均衡算法
01-21 925
像我之前做过的互联网广告平台，对请求响应时间要求非常高，为了解决南北方网络延迟的问题，在不同的区域部署了不同的IDC机房，请求通过域名访问后，会判断落到哪个IP响应时间短后续该ip的请求就会落到不同IP的机房中，大大减少了网络传输带来的响应时间的开销。在访问接口的时候，由于每次请求接口的响应时间不一样，通过轮询或加权轮询的时候，每台服务器的连接数不同，负载也就不同。根据请求的ip进行hash算法分发到不同的服务器，相同ip的请求转发到相同的服务器，这种适合保持会话，适用于服务器保持会话的场景。
博客
13 CAP理论和base理论
01-20 493
我们试想一下:假如A和B节点的网络通信中断了，在满足分区容错性的前提下，如果要保持AA和BB库的数据一致，那么就需要等待A和B节点的通信恢复，如果满足可用性，那么在A和B通信不可用的情况下，就会返回不一致的数据。CAP只能满足其中两个。有了网络分区的分区容错性之后§的前提条件下，我们选择强一致性或可用性对外提供服务，如果一致性和可用性都要满足的情况下，就只能返回错误的提示信息给到用户。一个系统提供的服务必须一直处于可用的状态，每次请求都能够获取到非错误的响应(不保证获取的数据为最新的数据)
博客
12 分布式事务
01-19 1299
我们拿mysql数据库来说，当数据库为单体数据库的时候，我们打开事务，执行sql为预执行阶段，最后commit时通过日志控制最终全部提交后存储到磁盘中，如果commit失败，可以通过日志控制回滚回来，但是当我们的数据库实例为多个的时候，不同的数据源，我们的日志已经无法控制落入磁盘的数据正常的回滚。事务的管理者协调事务的参与者，询问是否能够执行分布式事务的操作，各个事务的参与者在收到管理者消息时，锁定相关的资源，并应答管理着已经准备好了可以提交。如果有参与者返回不能提交事务则下达回滚的指令。
博客
11 RPC框架的主要实现原理
01-18 610
A机器的进程需要调用B机器上的服务，首先A机器的进程需要到注册中心找到B机器的IP地址和端口号信息，注册中心提供提供一个可靠的寻址方式。随着互联网的发展和互联网用户的不断增加，之前的单体应用在增加部署节点的带来的收益越来越小，这个时候我们把整体的应用架构拆分成多个应用，以提升程序运行的效率。服务的调用方，发起远程方法调用，把调用的参数信息序列化，再从注册中心拿到服务的提供者的地址，把调用转换成方法发起通信，在java服务于大多数企业家应用的时候，单体的应用架构成为主流，将所有业务部署在一起减少部署的成本。
博客
10 为什么系统需要引入分布式、微服务架构
01-16 1084
随着业务复杂度的提高，我们如果还是把程序维护在一个项目里面，不管是实体类的增加，JVM类加载的问题，性能的问题，项目复杂度的问题，这个时候需要我们对项目的复杂度进行拆解，也就是我们技术中说到的垂直拆分，随着我们在对整个系统进行拆分的时候遇到实际部署中遇到的一些问题，我们总结出DDD领域建模的方法论。随着应用的业务功能的扩展，团队也需要不断的扩张，各种复杂的业务会交织在一起，造成项目的臃肿，维护起来会越来越麻烦，最后修复功能的时候牵一发而动全身，系统很难维护。在微服务的架构中，每个服务独立负责自己的业务。
博客
9分布式微服务架构
01-14 778
然后我们在部署在不同机器的ip通过keepalive做出来一个虚拟的ip，当一台机器由于网络原因或者机器的原因不可达时，我们的keeplive写入数据库的时候会把虚拟的ip切到另外一台数据中执行。我们知道bonlog在同步的时候是有延时的，当切到另外一台机器时，上一台机器的binlog还未同步过来，我们往数据库中插入一条自增主键的数据时候，我们生成的id就会重复，这个时候就会造成很严重的问题。判断中心化和去中心化区分的关键点是分布式系统中的管理节点是由管理节点控制的还是由集群中的节点选举控制的。
博客
8 如何设计一个高并发系统
01-12 430
我们知道一个数据库的进程也是由数据库的引擎程序去执行我们的sql语句操作的，也就是说当我们对数据库的操作过于频繁的时候(并发高的情况下)，执行引擎也是处理不过来的，这个时候我们就要考虑分库的问题，如果只是数据库比较大但是操作并不频繁，这个时候引擎程序是能够处理的，但是由于需要从磁盘找数据，这个是比较耗时的动作，这个时候我们需要考虑分表的问题。还有我们做架构的整个一个逻辑体系和方法论的建立也不是一朝一夕的事情，不但需要我们不断的去学习，而且还有有强大的总结能力，提炼方法论的能力。主要关注下面的几个点。
博客
7 分布式定时任务调度框架
01-10 2746
我们在大型的复杂的系统下，会有大量的跑批，定时任务的功能，如果在独立的子项目中单独去处理这些任务，随着业务的复杂度的提高，大量的任务将很难进行统一的管理，出现bug以后问题也很难排查，最后将成为一种灾难。当执行器以集群方式部署的情况下,调度任务的策略选择"分片广播"的情况下，一次调度任务会以广播的形势触发集群中所有的执行器，同时传递分片参数，可以根据分片参数开发分片任务。4.源码也有很多值得学习的地方，虽然刚发布的时候会有很多资深的程序员诟病，但经过多年的发展维护，已经非常稳定。
博客
6 分布式限流框架
01-09 867
我们在固定窗口计数器的基础上对每一个时间窗口再进行时间上的切分，比如我们是按照1分钟100次请求的限制进行限流的，我们再将1分钟切成6份，就是10秒一个时间窗口，在每个细分的时间窗口中记录请求数量，时间从前一分钟的开始到前一分钟的结束为止，到了前一分钟的前10秒，我们的时间窗口从前一分钟的前10秒到下一分钟的前10秒结束。令牌桶算法的概念如下: 我们以固定的速率，生成令牌并放入桶中，如果令牌桶满了，生成的令牌将被丢弃。服务变为分布式的部署的情况下，我们只对单个节点进行限流的时候，其他节点并未得到限流。
博客
5 分布式ID
01-07 1072
比如我们一个应用实例不会在1毫秒生成4096个数值，我们可以把时间戳的值改成35位，把6个bit均分到机器id和服务id上，也就是说我们可以部署256*256=65536个实例。标识位为10位，由5位的机器id和5位的服务id组成。如果我们考虑以上问题可以在我们的程序中保留最近一次的生成时间，并拿来做校验，就可解决这个问题。一个用户体量比较大的分布式系统必然伴随着分表分库，分机房部署，单体的部署方式肯定是承载不了这么大的体量。从上图我们可以看出来雪花算法是64bit位的long类型的数值型的id。
博客
4 JAVA CAS
01-03 2131
在上述代码中，我们设置一个账户余额有10000元，然后设置1000个线程，每个线程转出10元，正确结果这里应该是0，AccountCas类中，我们定义了一个AtomicInteger对象，CAS的底层操作就是如withdraw函数中所示，获取到当前的值和将要修改的值，然后做一个比较并设置的操作，将Account对象的最新值和当前线程拿到的当前值做对比，如果相等，则返回true，是没有问题的，如果不相等，那么获取当前值，在while(true)中再次执行一次流程。所以达到了我们预期的效果。
博客
3 抢红包系统
01-02 838
计算好这些，我们还要考虑代理服务器能不能承载的问题，代理服务器的多活问题(一般nginx+keepalive)，如果是独立的机房部署用LVS(四层代理，通过修改局域网的协议包，实现转发，性能更好)是不是更好的选择，如果公司不差钱，用H5(银行喜欢用这个)是不是也可以，这些就涉及到技术选型的问题了.如果这个不能保障的时候，是不是需要在外面还套一层DNS轮询。如果我们能把这些做好，做技术选型的时候，即时我们对相关的技术没有深入的了解也可以通过查阅资料去了解。我们上面说的第一点，用户打开抢红包软件的时候。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值