近四年来的总结

2019, Dec 31    

来当前的公司已经近四年了,部门产品从0到1，公司从上市到退市，不少感触容我慢慢回忆。

回忆以产品技术发展为主，顺便聊聊产品及管理的理解。

ps:因为迁移blog，所以很多内容并没有很好的转过来，之前使用adoc+hugo发布我的blog。

2016 年 熟悉行业，重构现有产品，构建雏形

4月份加入该公司，负责公司的新产品线E-Navigation，原来的产品为电子海图。单从 E-Navigation 的概念上来说，就是一盘非常大的棋。

e-Navigation is about using modern technology to promote maritime information sharing for the benefit of safety and efficiency. The goal is to create solutions making it possible to collect, optimise and screen information and to exchange information efficiently between ships.

但不管大不大，最好的产品落地方式就是有客户需要且满足产品战略规划。

幸运的是，加入并负责的时候，该产品已经按照一家公司需要，定制了第一版。 但因为上线紧张而且无人运维（编写的人要负责电子海图的相关研发），所以此产品当时问题居多，基本上两三天就要人工上服务器重启一次。

所以当时加入公司，就立马投入到相关的工作中：

• 熟悉产品战略及当前第一版的业务逻辑（任何不依托业务需要的技术工作都是在耍流氓），代码逻辑，及公司计算资源等等
• 当前产品（1.0）有哪些问题，分析复杂度，要给出几个备选方案并作相应的修改。

先来说说第一版产品的业务及架构：

有三部分：数据服务端（java6）、岸用管理客户端（c++，及公司内部的海图SDK）、船用报文客户端（java）

交互通讯图（晚点补上来）

主要内容：

• 数据服务端：接收第三方接口的船用AIS信息，接收船用报文发送上来的报文。 转发用户所需的船舶AIS信息，将发送上来的报文解析并发送表格邮件给对应的管理员。

• 岸用管理客户端：接收服务端转发的船用AIS信息，并实时显示。

• 船用报文客户端：记录历史报文，发送报文邮件（可通过卫星站或者其他邮件服务站）。

当前的难点及问题：

• 服务端与管理端所有信息交互都是采用socket，不方便跟踪及定义问题。很多业务是无状态的，依旧采用了socket，不方便跟踪及定位问题。
• 服务端及报文端的数据通讯采用的是邮件通讯（将数据内容写在邮件内发送至指定的邮箱，服务端再读取邮箱内的内容）。 因为使用的是免费邮箱，所以经常会被拦截，其次因为经过不通的服务站，邮件内容格式会篡改，编码也会发生变化。
• 服务端的数据采用mysql进行存储，且写入大于读写。考虑到成本问题，并未将所有船位数据写入。
• 服务端部署在阿里云的ECS上，且IO写入速度非常低。
• 船端采用java编写的客户端，每次新船安装都需要携带几十M的java运行环境，非常不方便（客户提出来的）。
• 服务端会间歇阻塞掉，其表现为socket的信息交互没有对应的响应，或者不再读取邮件。
• 服务端在发送邮件的业务中，无法确定解析并格式化后的自定义邮件，是否投递成功。

解决思路：

• 让现有业务变得稳定，再进行其他复杂度上的设计。
• 复杂度优先级：性能 > 可扩展性 > 成本 > 可用性 > 安全 > 规模
• 对于单计算机上的服务端进行压测，确定当前硬件性能（之前提到的IO瓶颈也是这个时候暴露出来的），跟踪JVM运行情况等等。
• 重构及兼容替换。例如：对服务端关键逻辑进行重构保留原有接口及通讯方式，新增http接口对应一些无状态业务的请求， 客户端采用逐步替换保证其业务运行时的无缝衔接。 将一些不可跟踪业务变得可跟踪，方便定位问题。 将船用客户端进行重写，采用.net 2.0编写的客户端，因为船上的运行环境大多都为 win xp sp3及以上的windows系统。 将报文邮件的读取采用IMAP协议，充分利用该协议的特殊性来减少不必要的开发代码。
• 增加中间件，升级硬件满足需要。

ps:以上花了1.5个自然月，完成相关的工作。其中包含熟悉技术协议（AIS压缩语句等）、管理团队等等。 这段时间虽然压力大（主要是来自业务上的熟悉，海事行业的专业门槛很高）， 每天基本上10点回家,与其说1.5个自然月不说是工作月，因为我只休了一天。 但是呢，过的非常充实，我个人还是喜欢有挑战的事情。

业务服务的构建

这个回忆录就慢慢完善吧。最近开始要忙新的事情了再加上过年和肺炎。

最初的业务服务只是提供了基本所需的服务。 数据相关的管理操作非常麻烦，而且其他的业务也接踵而至，当务之急就是建立一个可视化操作的管理后台。 为了解耦及保证服务之间的独立性，虽然增加了我的工作量，但依然选择纯前端进行构建，并起名为E-Studio. 第一版采用angularJs + bootstrap并对接基于前期工作中完成的API, 根据现有业务快速构建。

与此同时，基于海图的web应用在随后工作中启动，web海图对我来说，也是一个不小的挑战：

1. 基础概念的理解，坐标系，瓦片系统等等
2. 底层的海图必然需要依赖自研的SDK进行切图，但该SDK是单线程处理，加上要切全球图，数据庞大，所以切图效率上有很大问题。
3. 海图显示+船位的显示这是最业务功能，但加上手势操作和后期的扩展性，技术的选型要考虑的非常充分

再最后选用openlayers作为底层框架，多实例启动SDK进行切图，同时将切好的图片上传至服务器上。 初期上线，在我们的服务器上可以容纳100同时访问。但随着用户数增加，原本的小水管服务器也无法支撑100人的同时访问。 通过加入CDN来分担远程资源的使用，将存储移植至OSS，这样上千万的访问也可以抗住。

其次，web海图还有查询船舶的航线规划一项，基于后面的流量及并发量的提升， 我们将航线记录提前生成好静态文件存放至oss，这样不仅提升了性能，满足了可用性，还节省了成本。

建立本地计算资源虚拟化（集群），数据仓储，数据分析

占位

Hadoop(HDFS) ES

devops

占位

Jenkins Docker ELK

服务治理

占位

未完待续