仅以此文记录纯粹自研日记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列一下：
- 坐标换算Api：http://api.map.baidu.com/ag/coord/convert?from=0&to=4&x=xxx&y=xxxx
- 周边设施查询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的工作原理，我能不能自己做一个简易的域名映射。
以下是苦思冥想找到的解决方案
首先在路由配置端口转发。这个说明白点，路由有一个公网ip，所有流向路由的流量，一旦落入了配置好的转发端口，就自动将流量转发到指定的内网机器，也就是我的服务器。这样相当于服务器获取到了一个公网ip，可以通过 公网ip:指定端口 访问数据库，ssh，web应用了。
-
接下来的问题是，路由重启后，这个公网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 等等费用了！
