Osheep

时光不回头,当下最重要。

吾刻此时-手记

仅以此文记录纯粹自研日记App 吾刻此时 的诞生,优化,推广历程。

算是一个老码农对自己多年码农生涯的一个总结和交待。

期间碰到的各种问题以及解决方案也希望对大家有所启示。

大家就当瞧故事,看看一个app是怎么做出来,推广开的。

2017-01-28

过年回家,闲着无聊。之前一直听某人抱怨,出去high的时候不敢发朋友圈,担心老板同事看到说自己不务正业。微信人太多,又实在是懒得去分组,所以按分组屏蔽那个功能也是懒得用。

想想自己出去玩的照片着实拍了不少,但是都丢在硬盘里面落灰,一年到头也难有机会翻出来看看。

然而还是想着要把一些人,一些事情记录下来,年深日久,有个回忆和念想。基于以上两点,捉摸着既然是个老码农,不如自己做个日记app吧,可以不被老板发现,还可以隔三差五给自己推个消息,点开看看多少天前发生了一件什么有趣儿的事儿。想到这里,一把年纪了居然还有种莫名的小兴奋。

晚上大概设想了一下功能,用户注册登录的细节,起了个新工程。琢磨着这么小一个app估计过年期间就能有个初号版本。

名字就叫时刻,解读为 吾刻此时 。随手刻时于此, 不亦乐乎!

2017-02-01

App基本有个样子了,虽说功能就是一个事件列表,一个新增事件,一个随机的事件提醒,外加一个定位。这几天几乎是天天到2,3点,年纪大了还真是有点扛不住,觉得虚。

大概概括下app的技术架构:
App前端是Ionic混合框架,基于Angular Js。这种混合框架的好处是回头可以很小的cost迁移Android,做的好体验也不输native开发。

后端用的java 的Srping Boot,辅助Spring Security的Oauth。App登录获取一个令牌,每次请求接口数据放Header里。

接口就那么几个,事件的增删改查+图片上传。

就这么几个功能,做得太急了,还是累个够呛。感觉这个年没有休息好,年后还一堆事儿,明天得好好睡觉了。

2017-02-11

今天完善了一下事件定位。用的是Codova的开源定位插件cordova-plugin-geolocation,获取当前经纬度,然后用百度的位置解析api去反查自己周边的各种设施。

这个东西有个毛病,就是定位的经纬度总有偏离,查了一下需要换算成百度的经纬度才准确。
于是用百度另外一个api去做经纬度换算。
可以用百度这个经纬度拾取工具来看换算后的经纬度是否准确
百度地图-拾取坐标系统。 勾上坐标反查,输入经纬度,然后可以看到地图上是在哪里。感觉挺有用的,跟大家分享一下。

几个百度Api列一下:

  1. 坐标换算Api:http://api.map.baidu.com/ag/coord/convert?from=0&to=4&x=xxx&y=xxxx
  2. 周边设施查询Api:http://api.map.baidu.com/place/v2/search?page_size=20&scope=1&radius=1500&output=json&ak=yourak&location=纬度,经度&query=xxx(查询关键字,娱乐,机场等等)

具体的换算过程不详述了,这块被坑到的朋友可以私信聊。

2017-03-22

今天算是正式上线了,Appstore新发了一个版本,优化了关键词。
现在还是要搜 ”我的 时刻“才能翻到,看看这版关键词优化后能不能好些。
有个网站不错,可以帮忙分析查询关键词
ASP优化助手

在一个发小群里发了一下app下载链接,结果发现只有一个人是iphone,然后逼着给了5星好评。

晚上又自己改了几个小bug,我想把一个app一直推到日活1w是一个很有意思的事儿,大概能学到很多东西吧。

2017-03-23

今天检查服务器状况,无意中发现有个777的应用在跑,点开发现是个病毒应用,可以随意删除服务器文件,哥的服务器第一次被进攻了。

满头汗的先把这个应用删了,然后思考这个东西怎么进来的。最后想来想去,是不是用tomcat管理应用被破解了,然后进来部署了这个东西。
查看了tomcat-users.xml,最近一次更改时间是3月14日,当时为了加probe监控,感觉是这个问题。

于是先改掉了admin密码,然后直接把tomcat自带的后台应用删了。
probe也考虑干掉,太尼玛危险了。
还好攻击者只是放了个病毒应用,目前没有发现删了什么东西,这么一想数据库服务器和应用服务器隔离也是很有必要的啊!

2017-03-24

今天给一哥们安利app的时候,说短信验证码收不到。
马上登陆aws主机看了下日志,发现调用阿里大于短信接口timeout,直接ping阿里的网站,发现ping不通。感觉是网络问题,可是之前一直是好的。

搞了半天把弹性ip解除主机绑定,然后重新绑定一次问题解决。
不知道是不是aws的bug,未来不会老这样吧,感觉心好慌==

2017-03-27

今天进服务器不小心看了下top,发现cpu利用率99%,一个4137的进程。

<pre>
top – 17:24:52 up 22 days, 4:48, 1 user, load average: 3.06, 2.36, 2.15
Tasks: 75 total, 2 running, 73 sleeping, 0 stopped, 0 zombie
Cpu(s): 17.2%us, 14.7%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 1.1%si, 67.0%st
Mem: 1019280k total, 930688k used, 88592k free, 64172k buffers
Swap: 0k total, 0k used, 0k free, 121164k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4137 root 20 0 341m 880 364 S 98.4 0.1 2356:15 e
2618 ec2-user 20 0 131m 3760 1828 S 0.7 0.4 21:01.29 redis-server
9035 root 20 0 2472m 656m 5512 S 0.7 65.9 36:40.24 java
3 root 20 0 0 0 0 R 0.3 0.0 34:46.62 ksoftirqd/0
1 root 20 0 19636 2296 1976 S 0.0 0.2 0:02.16 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
4 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
6 root 20 0 0 0 0 S 0.0 0.0 0:05.56 kworker/u30:0
7 root 20 0 0 0 0 S 0.0 0.0 4:34.70 rcu_sched
8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh
9 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/0
10 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kdevtmpfs
11 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 netns
12 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 perf
15 root 20 0 0 0 0 S 0.0 0.0 0:00.02 xenwatch
20 root 20 0 0 0 0 S 0.0 0.0 0:00.00 xenbus
21 root 20 0 0 0 0 S 0.0 0.0 0:39.64 kworker/0:1
</pre>

赶紧看了下是什么鬼。
<pre>
ps -ef|grep 4137
root 4137 1 25 Mar21 ? 1-15:16:54 /home/ec2-user/web/apache-tomcat-7.0.702/webapps/7777/e
ec2-user 28480 28390 0 17:25 pts/1 00:00:00 grep –color=auto 4137
</pre>
发现上次那个7777的应用居然还留了个进程在跑,也不知道是干嘛的。
删了。跑了这么久都没发现,好恶心。

2017-03-29

今天不小心看了一眼aws的账单,发现3月份被扣了200多美刀,简直丧心病狂!
看了下是因为ec2 异常留出流量,估计有1个T了,马上把机器都关掉,App下架。
流量增大从21号开始,看来就是被黑的那天,尼玛。
在AWS提ticket,希望能退回费用。

另外,下定决心,无论如何要用自己的机器搭建服务器了,以后这种云端绑定信用卡的服务真心不敢用了。

2017-03-30

和AWS客服联系退款。开始着手灾后重建。
先把之前淘汰的一台笔记本翻出来,硬盘全部格式化掉,重装了linux。
这台本子三年前买的,配置还不错,自己还换了SSD,16个G内存,配置应该秒杀AWS的免费机了,接下来头疼的是如何获取固定ip。

花生壳搞得很麻烦,而且网上口碑也不大好,不知道是不是被竞争对手黑的。反正我是信了,然后试用了一下nat123,一次成功。想了一下原理就是注册了本机到nat123服务器的链接通道,然后所有请求都从nat123服务器转发。

速度肯定是慢,但是还勉强能接受,不知道服务器搭起来,跑的会多慢,这个时候不看机器配置,纯粹是看带宽。

2017-03-31

应用搭起来了,利用nat123映射出服务端口,但是巨慢。。。一张图片刷了大概半分钟,看来要另想办法。作为一个在IT摸爬滚打了这么多年的老油条,思索了一下nat123的工作原理,我能不能自己做一个简易的域名映射。

以下是苦思冥想找到的解决方案

  1. 首先在路由配置端口转发。这个说明白点,路由有一个公网ip,所有流向路由的流量,一旦落入了配置好的转发端口,就自动将流量转发到指定的内网机器,也就是我的服务器。这样相当于服务器获取到了一个公网ip,可以通过 公网ip:指定端口 访问数据库,ssh,web应用了。

  2. 接下来的问题是,路由重启后,这个公网ip是会变的。查了一下电信固定ip的价格,每个月最低5k吧,完全不敢想。

    于是又开始琢磨野路子,是不是可以自己做一个最原始简单的域名解析呢?

最简易文件型域名解析登场

新建了一个叫dns的文本文件,里面写入了我当前的公网ip。
<pre>
123.123.123.123
</pre>

然后把这个文件传到了阿里云oss存储上,获得了一个文件的访问地址:
<pre>
http://xxxx/xxx/dns
</pre>

在app启动的时候,先http get这个地址,获取我当前的公网ip,然后接口调用就可以通过这个公网ip来调用我的服务器的接口了。

最后服务器上写了一个python程序,每隔半小时检查当前路由的公网ip,并覆盖阿里云上的dns文件。

至此,一个借助阿里云的文件DNS解析完成了!!

附一下python脚本,仅供参考



cat ossDns.py

# -*- coding: utf-8 -*-

import os
import sys
import tempfile
import urllib2
import oss2

# 以下代码展示了进度条功能的用法,包括上传进度条和下载进度条。


# 首先初始化AccessKeyId、AccessKeySecret、Endpoint等信息。
# 通过环境变量获取,或者把诸如“<你的AccessKeyId>”替换成真实的AccessKeyId等。
access_key_id = 'xxxxxx'
access_key_secret = 'xxxxxx'
bucket_name = 'xxxxxx'
endpoint = 'oss-cn-shanghai.aliyuncs.com'

#获取当前本机外网ip
req = urllib2.Request('http://members.3322.org/dyndns/getip');

response = urllib2.urlopen(req)
ip= response.read()
ip=ip.rstrip()
print ip



# 确认上面的参数都填写正确了
for param in (access_key_id, access_key_secret, bucket_name, endpoint):
    assert '<' not in param, '请设置参数:' + param

def percentage(consumed_bytes, total_bytes):
    """进度条回调函数,计算当前完成的百分比

    :param consumed_bytes: 已经上传/下载的数据量
    :param total_bytes: 总数据量
    """
    if total_bytes:
        rate = int(100 * (float(consumed_bytes) / float(total_bytes)))
        print('\r{0}% '.format(rate))
        sys.stdout.flush()

def _prepare_temp_file(content):
    """创建临时文件
    :param content: 文件内容
    :return 文件名
    """
    fd, pathname = tempfile.mkstemp(suffix='exam-progress-')
    os.write(fd, content)
    os.close(fd)
    return pathname

key = 'dns'

# 创建Bucket对象,所有Object相关的接口都可以通过Bucket对象来进行
bucket = oss2.Bucket(oss2.Auth(access_key_id, access_key_secret), endpoint, bucket_name)

"""
流式上传
"""
# 带有进度条的覆盖上传
bucket.put_object(key,ip, progress_callback=percentage)


测试结果

速度感人!不再依赖nat123憋屈的带宽,直接就是本地的上载速度,非常非常顺滑。后面觉得图片慢,去升级下宽带就ok了,哈!哈!哈!哈!

App吾刻此时已经重新上架,再也没人收哥的流量费,磁盘空间,弹性ip,cpu,blah blah blah 等等费用了!

点赞