来阿里之前，工作了4年半，其中3年半在某O2O型(餐饮)创业公司。
该公司的业务是基于城市和用户经度纬度，查找附件的餐饮商店和商品，下单和配送。
创业公司，是一类特殊的公司。条件简单，成长过程明显，随时间轴变化快。
这里以一个技术人的角度，讲一下我所经历的创业公司的技术发展历程。
业务角色
基础环境
A.草莽时期
架构图：
特点：一穷二白，实现功能优先。大量功能杂糅在一个工程里。工程数量少。
主要事项：
1、工程数少，环境简单。front.war，前台网站，还没有用户端手机。back.war，后台，订单、物流等。ws.war，定时器，支付，物流等。mysql，主从。memcached一个。mongodb一个，存图片。
2、机房。使用南京电信托管机房，自备物理机，装配虚拟机。
3、技术人员少，一共5个左右，没有测试。技术力量偏弱。
4、代码大量重复，功能大量重复。没有复用性。
与我相关的：
1、开发搜索，我一个人，在front.war中。当时用"sql语句+memcached+java代码"。
搜索商店，过滤条件包括关键词、商店类型、距离范围、价格范围、配送方式、距离排序、平均价格排序、评分排序、分页等。用城市id查出一个城市内的商店，放入memcached。用城市id从缓存中查出商店列表，用用户经度纬度算距离，用各种过滤条件过滤，然后分页。
搜索商品，先用前面的方法找到附近的商店，然后加上商店id列表和商品名从mysql查商品列表，然后拼接商店和商品，过滤各种条件，分页。
代码比较混乱，效率低。
2、开发支付，我一个人，在ws.war包中。主要功能是在线支付和在线退款。
独立设计了订单支付表，退款批次表，退款条目表。首先接的支付方式是支付宝，然后是南京银行。
2种支付方式都是定制代码，重用性差，不好扩展。南京银行刚接入时，给了一点钱做优惠活动，用南京银行支付减免多少元。
3、我还开发了用户端其他需求，地图页，用户账户，领券活动等。
B.分家时期
架构图：
特点：部分功能独立成子系统，并且代码重构。
主要事项：
1、独立子系统。handset.war，用户端手机，从ws独立。pay.war，支付，从ws独立。
2、开始使用搜索引擎。使用solr来做部分搜索功能。
3、代码大量重复，功能大量重复。复用性还是差。
与我相关的：
1、手机功能从ws独立成手机子系统，我一人负责，拥有独立子域名handset.xxx.com，handset.war，拥有独立的centOS和tomcat。代码重构，代码做了裁剪，去掉不相关的东西。
原有一个iOS开发，新来了一个安卓开发。手机端的使用体验待改进。
2、支付功能从ws独立成支付子系统，我一人负责，拥有独立子域名pay.xxx.com，独立成pay.war。代码做了重构，原来的结构痛点明显，不好扩展。使用了门面模式、策略模式。
门面模式，几个统一的对外接口，网页支付接口，手机支付接口，二维码支付接口，退款接口等，定好每个接口的参数，简洁明了。
策略模式，抽象出支付父类PayHandler和父类方法（网页支付、手机支付、二维码支付、退款）。具体的某种支付方式是支付父类的子类，如支付宝网页支付AlipayHandler，支付宝手机支付AlixpayHandler。
代码结构清晰，扩展性非常好。
3、学习和使用solr做搜索。单独分centOS和tomcat，部署一个solr。
ws引入solr API，写定时器，全量和增量，把商店和商品写入solr。front引入solr API，直接查询solr。
主搜索页，因为配送方式条件和距离有关不好实现，一直没接入solr。关键词下拉框使用solr，使用笨的方法，传入附近的可见的商店id列表，和关键词，速度还是挺快的。
商家接入了南京的几家超市，超市的单店搜索页使用了solr，搜索效率很高。
C.精耕细作时期
架构图：
特点：推广服务化。增加更多子系统。业务单元独立。
主要事项：
1、maven推广父子工程结构，common、client、biz、web、task。对外暴露client。
2、全面推广服务化框架dubbo。
3、增加子系统，单点登录，搜索引擎，列表页，标签系统，商家中心，活动中心，权限中心，物流中心等。
4、推广redis，基本代替memcached。redis有丰富数据结构，做业务开发更方便。
5、mysql做了一部分垂直分库，某些业务子系统放一个mysql。还没有做分表，数据量没到。
6、使用ucloud，整体环境迁移到ucloud。
与我相关的：
1、独立开发了单点登录系统。接入前台用户和后台用户，用redis做登陆信息缓存，用dubbo做服务化。效果不错。
2、与他人合作，开发搜索引擎系统。
新建search工程，包装solr的api，新建几个简单的管理页面（如全量增量更新，更新指定记录），对外用dubbo提供查询服务。新建地图切块算法，利用solr的倒排索引，解决部分范围内搜索和配送方式过滤的问题，但是solr的地图切块的索引文件非常大，是个新问题。
原有的搜索功能全部切换到搜索引擎，包括列表页、手机搜索、关键词下拉框等。
3、独立开发了列表页工程。接入搜索引擎的服务。
4、与他人合作，开发标签系统。与活动中心配合，给商店、商品打标。
5、部署codis，一个redis集群。
6、管理基础环境，如dubboAdmin，solr，zookeeper。
7、尝试新的技术hbase，hive。
这里举例，用支付和搜索，讲述技术进化之路。
A.支付进化
进化架构图：
详细讲解：
1、早期，只有我一个人整。包揽了需求，开发，测试，维护等。接入的支付方式少，代码写死了。简单又粗暴。
2、后续，还是只有我一个人整，支付方式渐渐增多，工程独立，代码重构。使用了门面模式和策略模式，扩展性好，工程比较优雅。
3、后续的后续，局部优化，交接给单独的支付开发人员。有难度的需求，我也帮忙协助。
4、支付和退款都是异步的，思维观念需要改变和适应。比如支付了订单，等几秒钟支付状态改变。
5、异步体现在回调通知，主要有支付回调通知，退款回调通知。
6、回调通知用http，如"http://xxxx/xx.do"，url一般不要带参数，数据用post。
7、严重依赖外部api，因为支付服务是外部系统提供的。有些外部支付服务做的不够好，如回调通知延迟十几分钟。
8、常用的数据校验方式：多参数拼接成一个字符串，信息摘要，非对称加密RSA，数字签名，远程动态生成流水号
9、网页支付接口，返回html代码，直接跳转到外部支付页面，比如支付宝页面。
10、手机支付接口，返回json，包含objType，objData等。objType是手机网页支付类型时，objData是url。objType是手机APP支付类型时，objData是对象，包含key、value对。
11、核心的表是支付表，退款批次表，退款条目表。3个表满足了主要的需求。
B.搜索进化
进化架构图：
详细讲解：
1、早期，只有我一个人整，用的"sql语句+memcached+java代码"，简单又粗暴。
2、之后，还是只有我一个人整，部署了solr。由于具体的业务规则限制，不知道怎么实现，主搜索没有用solr，某些能用solr的地方用了solr。
3、后续，有别人帮忙。我搭建了solr主从集群，合作开发了地图切块功能和搜索工程，解决了部分业务规则搜索难题，主搜索接入search。
4、倒排索引，用关键词查询文档ID。主流搜索引擎是lucene，solr，elasticSearch。
5、solr布置到tomcat，读写用http。
6、solr提供主从结构，一主多从。数据有版本号version，solr(从)定时拉取数据。
7、solr的常用功能，新建实例，配置字段，分词，查询，分组统计，排序，分页，函数。
8、使用IK中文分词器，集成到solr中。
9、使用solr的接口类+lucene jar包+solr jar包，可以开发自定义实现类，配置到solr中使用。
10、search工程，包装solr API，对外提供dubbo服务。search和solr对应，一主多从。
1、创业公司挺锻炼人的。资源不足，强调个人能力。一个人抗几个系统。
2、技术方面，修行靠个人。要啃枯燥乏味的技术书籍。
3、注重知识的广度和深度，培养综合能力。
4、在繁琐的工作中，培养优秀的品质，如细心和耐力。
5、按照时间线，由集中到分散，分布式、服务化是主流。
6、系统的重构和优化，是个长期的过程。
7、开发要有产品观。在大版本迭代时，产品观会非常强烈。
Bye ##
该公司的业务是基于城市和用户经度纬度，查找附件的餐饮商店和商品，下单和配送。
创业公司，是一类特殊的公司。条件简单，成长过程明显，随时间轴变化快。
这里以一个技术人的角度，讲一下我所经历的创业公司的技术发展历程。
- 基本信息
业务角色
| 用户 | 普通消费者，需要餐饮服务 |
| 商家 | 饭馆、酒店，提供餐饮服务 |
| 客服 | 处理订单流程，处理用户和商家的问题 |
| 配送员 | 从商家取餐，送到用户 |
基础环境
| centOS | linux系统 |
| tomcat | jvm容器 |
| nginx | 反向代理，负载均衡 |
| mysql | 关系型数据库 |
| solr | 基于lucene的搜索引擎 |
| redis | nosql，基于key-value |
| mongodb | nosql，基于对象 |
| dubbo | 服务化框架 |
- 发展历程
A.草莽时期
架构图：
特点：一穷二白，实现功能优先。大量功能杂糅在一个工程里。工程数量少。
主要事项：
1、工程数少，环境简单。front.war，前台网站，还没有用户端手机。back.war，后台，订单、物流等。ws.war，定时器，支付，物流等。mysql，主从。memcached一个。mongodb一个，存图片。
2、机房。使用南京电信托管机房，自备物理机，装配虚拟机。
3、技术人员少，一共5个左右，没有测试。技术力量偏弱。
4、代码大量重复，功能大量重复。没有复用性。
与我相关的：
1、开发搜索，我一个人，在front.war中。当时用"sql语句+memcached+java代码"。
搜索商店，过滤条件包括关键词、商店类型、距离范围、价格范围、配送方式、距离排序、平均价格排序、评分排序、分页等。用城市id查出一个城市内的商店，放入memcached。用城市id从缓存中查出商店列表，用用户经度纬度算距离，用各种过滤条件过滤，然后分页。
搜索商品，先用前面的方法找到附近的商店，然后加上商店id列表和商品名从mysql查商品列表，然后拼接商店和商品，过滤各种条件，分页。
代码比较混乱，效率低。
2、开发支付，我一个人，在ws.war包中。主要功能是在线支付和在线退款。
独立设计了订单支付表，退款批次表，退款条目表。首先接的支付方式是支付宝，然后是南京银行。
2种支付方式都是定制代码，重用性差，不好扩展。南京银行刚接入时，给了一点钱做优惠活动，用南京银行支付减免多少元。
3、我还开发了用户端其他需求，地图页，用户账户，领券活动等。
B.分家时期
架构图：
特点：部分功能独立成子系统，并且代码重构。
主要事项：
1、独立子系统。handset.war，用户端手机，从ws独立。pay.war，支付，从ws独立。
2、开始使用搜索引擎。使用solr来做部分搜索功能。
3、代码大量重复，功能大量重复。复用性还是差。
与我相关的：
1、手机功能从ws独立成手机子系统，我一人负责，拥有独立子域名handset.xxx.com，handset.war，拥有独立的centOS和tomcat。代码重构，代码做了裁剪，去掉不相关的东西。
原有一个iOS开发，新来了一个安卓开发。手机端的使用体验待改进。
2、支付功能从ws独立成支付子系统，我一人负责，拥有独立子域名pay.xxx.com，独立成pay.war。代码做了重构，原来的结构痛点明显，不好扩展。使用了门面模式、策略模式。
门面模式，几个统一的对外接口，网页支付接口，手机支付接口，二维码支付接口，退款接口等，定好每个接口的参数，简洁明了。
策略模式，抽象出支付父类PayHandler和父类方法（网页支付、手机支付、二维码支付、退款）。具体的某种支付方式是支付父类的子类，如支付宝网页支付AlipayHandler，支付宝手机支付AlixpayHandler。
代码结构清晰，扩展性非常好。
3、学习和使用solr做搜索。单独分centOS和tomcat，部署一个solr。
ws引入solr API，写定时器，全量和增量，把商店和商品写入solr。front引入solr API，直接查询solr。
主搜索页，因为配送方式条件和距离有关不好实现，一直没接入solr。关键词下拉框使用solr，使用笨的方法，传入附近的可见的商店id列表，和关键词，速度还是挺快的。
商家接入了南京的几家超市，超市的单店搜索页使用了solr，搜索效率很高。
C.精耕细作时期
架构图：
特点：推广服务化。增加更多子系统。业务单元独立。
主要事项：
1、maven推广父子工程结构，common、client、biz、web、task。对外暴露client。
2、全面推广服务化框架dubbo。
3、增加子系统，单点登录，搜索引擎，列表页，标签系统，商家中心，活动中心，权限中心，物流中心等。
4、推广redis，基本代替memcached。redis有丰富数据结构，做业务开发更方便。
5、mysql做了一部分垂直分库，某些业务子系统放一个mysql。还没有做分表，数据量没到。
6、使用ucloud，整体环境迁移到ucloud。
与我相关的：
1、独立开发了单点登录系统。接入前台用户和后台用户，用redis做登陆信息缓存，用dubbo做服务化。效果不错。
2、与他人合作，开发搜索引擎系统。
新建search工程，包装solr的api，新建几个简单的管理页面（如全量增量更新，更新指定记录），对外用dubbo提供查询服务。新建地图切块算法，利用solr的倒排索引，解决部分范围内搜索和配送方式过滤的问题，但是solr的地图切块的索引文件非常大，是个新问题。
原有的搜索功能全部切换到搜索引擎，包括列表页、手机搜索、关键词下拉框等。
3、独立开发了列表页工程。接入搜索引擎的服务。
4、与他人合作，开发标签系统。与活动中心配合，给商店、商品打标。
5、部署codis，一个redis集群。
6、管理基础环境，如dubboAdmin，solr，zookeeper。
7、尝试新的技术hbase，hive。
- 进化之路
这里举例，用支付和搜索，讲述技术进化之路。
A.支付进化
进化架构图：
详细讲解：
1、早期，只有我一个人整。包揽了需求，开发，测试，维护等。接入的支付方式少，代码写死了。简单又粗暴。
2、后续，还是只有我一个人整，支付方式渐渐增多，工程独立，代码重构。使用了门面模式和策略模式，扩展性好，工程比较优雅。
3、后续的后续，局部优化，交接给单独的支付开发人员。有难度的需求，我也帮忙协助。
4、支付和退款都是异步的，思维观念需要改变和适应。比如支付了订单，等几秒钟支付状态改变。
5、异步体现在回调通知，主要有支付回调通知，退款回调通知。
6、回调通知用http，如"http://xxxx/xx.do"，url一般不要带参数，数据用post。
7、严重依赖外部api，因为支付服务是外部系统提供的。有些外部支付服务做的不够好，如回调通知延迟十几分钟。
8、常用的数据校验方式：多参数拼接成一个字符串，信息摘要，非对称加密RSA，数字签名，远程动态生成流水号
9、网页支付接口，返回html代码，直接跳转到外部支付页面，比如支付宝页面。
10、手机支付接口，返回json，包含objType，objData等。objType是手机网页支付类型时，objData是url。objType是手机APP支付类型时，objData是对象，包含key、value对。
11、核心的表是支付表，退款批次表，退款条目表。3个表满足了主要的需求。
B.搜索进化
进化架构图：
详细讲解：
1、早期，只有我一个人整，用的"sql语句+memcached+java代码"，简单又粗暴。
2、之后，还是只有我一个人整，部署了solr。由于具体的业务规则限制，不知道怎么实现，主搜索没有用solr，某些能用solr的地方用了solr。
3、后续，有别人帮忙。我搭建了solr主从集群，合作开发了地图切块功能和搜索工程，解决了部分业务规则搜索难题，主搜索接入search。
4、倒排索引，用关键词查询文档ID。主流搜索引擎是lucene，solr，elasticSearch。
5、solr布置到tomcat，读写用http。
6、solr提供主从结构，一主多从。数据有版本号version，solr(从)定时拉取数据。
7、solr的常用功能，新建实例，配置字段，分词，查询，分组统计，排序，分页，函数。
8、使用IK中文分词器，集成到solr中。
9、使用solr的接口类+lucene jar包+solr jar包，可以开发自定义实现类，配置到solr中使用。
10、search工程，包装solr API，对外提供dubbo服务。search和solr对应，一主多从。
- 总结
1、创业公司挺锻炼人的。资源不足，强调个人能力。一个人抗几个系统。
2、技术方面，修行靠个人。要啃枯燥乏味的技术书籍。
3、注重知识的广度和深度，培养综合能力。
4、在繁琐的工作中，培养优秀的品质，如细心和耐力。
5、按照时间线，由集中到分散，分布式、服务化是主流。
6、系统的重构和优化，是个长期的过程。
7、开发要有产品观。在大版本迭代时，产品观会非常强烈。
Bye ##
