August 2017

1、业务架构：从单体式到微服务 K歌亭是唱吧的一条新业务线，旨在提供线下便捷的快餐式K歌方式，用户可以在一个电话亭大小的空间里完成K歌体验。K歌亭在客户端有VOD、微信和Web共三个交互入口，业务复杂度较高，如长连接池服务、用户系统服务、商户系统、增量更新服务、ERP等。对于服务端的稳定性要求也很高，因为K歌亭摆放地点不固定，很多场所的运营活动会造成突发流量。 为了快速开发上线，K歌亭项目最初采用的是传统的单体式架构，但是随着时间的推移，需求的迭代速度变得很快，代码冗余变多，经常会出现牵一发动全身的改动。重构不但会花费大量的时间，而且对运维和稳定性也会造成很大的压力；此外，代码的耦合度高，新人上手较困难，往往需要通读大量代码才不会踩进坑里。 鉴于上述弊端，我们决定接下来的版本里采用微服务的架构模型。从单体式结构转向微服务架构中会持续碰到服务边界划分的问题：比如，我们有user 服务来提供用户的基础信息，那么用户的头像和图片等是应该单独划分为一个新的service更好还是应该合并到user服务里呢？如果服务的粒度划分的过粗，那就回到了单体式的老路；如果过细，那服务间调用的开销就变得不可忽视了，管理难度也会指数级增加。目前为止还没有一个可以称之为服务边界划分的标准，只能根据不同的业务系统加以调节，目前K歌亭拆分的大原则是当一块业务不依赖或极少依赖其它服务，有独立的业务语义，为超过2个的其他服务或客户端提供数据，那么它就应该被拆分成一个独立的服务模块。 在采用了微服务架构之后，我们就可以动态调节服务的资源分配从而应对压力、服务自治、可独立部署、服务间解耦。开发人员可以自由选择自己开发服务的语言和存储结构等，目前整体上使用PHP做基础的Web服务和接口层，使用Go语言来做长连接池等其他核心服务，服务间采用thrift来做RPC交互。 2、系统架构的构思与解读 2.1 容器编排 唱吧K歌亭的微服务架构采用了Mesos和Marathon作为容器编排的工具。在我们选型初期的时候还有三个其他选择，Kubernetes、 Swarm、 DC/OS： DC/OS：作为Mesosphere公司的拳头产品，基本上是希望一统天下的节奏。所以组件很多，功能也很全面。但是对于我们在进行微服务架构初期，功能过于庞大，学习成本比较高，后期的生产环境维护压力也比较大。 Swarm：Docker公司自己做的容器编排工具，当时了解到100个以上物理节点会有无响应的情况，对于稳定性有一些担忧。 Kubernetes：Google开源的的容器编排工具，在选型初期还没有很多公司使用的案例，同时也听到了很多关于稳定性的声音，所以没有考虑。但是在整个2016年，越来越多的公司开始在线上使用Kubernetes，其稳定性逐步提高，如果再选型应该也是个好选择。 Mesos：因为了解到Twitter已经把Mesos用于生产环境，并且感觉架构和功能也相对简单，所以最后选择了Mesos+Marathon作为容器编排的工具。   2.2 服务发现 我们采用了etcd作为服务发现的组件，etcd是一个高可用的分布式环境下的 key/value 存储服务。在etcd中，存储是以树形结构来实现的，非叶结点定义为文件夹，叶结点则是文件。我们约定每个服务的根路径为/v2/keys/service/$service_name/，每个服务实例的实际地址则存储于以服务实例的uuid为文件名的文件中，比如账户服务account service当前启动了3个可以实例，那么它在etcd中的表现形式则如下图: 当一个服务实例向etcd写入地址成功时我们就可以认为当前服务实例已经注册成功，那么当这个服务实例由于种种原因down掉了之后，服务地址自然也需要失效，那么在etcd中要如何实现呢？ 注意，图中的每个文件有一个ttl值，单位是秒，当ttl的值为0时对应的文件将会被etcd自动删除。当每个服务实例启动之后第一次注册时会把存活时间即ttl值初始化为10s，然后每隔一段时间去刷新ttl，用来像向etcd汇报自己的存活，比如7s，在这种情况下基本啥上可以保证服务有效性的更新的及时性。如果在一个ttl内服务down掉了，则会有10s钟的时间是服务地址有效；而服务本身不可用，这就需要服务的调用方做相应的处理，比如重试或这选择其它服务实例地址。 我们服务发现的机制是每个服务自注册，即每个服务启动的时候先得到宿主机器上面的空闲端口；然后随机一个或多个给自己并监听，当服务启动完毕时开始向etcd集群注册自己的服务地址，而服务的使用者则从etcd中获取所需服务的所有可用地址，从而实现服务发现。 同时，我们这样的机制也为容器以HOST的网络模式启动提供了保证。因为BRIDGE模式确实对于网络的损耗太大，在最开始就被我们否决了，采用了HOST模式之后网络方面的影响确实不是很大。 2.3 监控，日志与报警 我们选择Prometheus汇总监控数据，用ElasticSearch汇总日志，主要的原因有： 生态相对成熟，相关文档很全面，从通用的到专用的各种exporter也很丰富。 查询语句和配置简单易上手。 原生具有分布式属性。 所有组件都可以部署在Docker容器内。 Mesos Exporter，是Prometheus开源的项目，可以用来收集容器的各项运行指标。我们主要使用了对于Docker容器的监控这部分功能，针对每个服务启动的容器数量，每个宿主机上启动的容器数量，每个容器的CPU、内存、网络IO、磁盘IO等。并且本身他消耗的资源也很少，每个容器分配0。2CPU，128MB内存也毫无压力。 在选择Mesos Exporter之前，我们也考虑过使用cAdvisor。cAdvisor是一个Google开源的项目，跟Mesos Exporter收集的信息八成以上都是类似的；而且也可以通过image字段也可以变相实现关联服务与容器，只是Mesos exporter里面的source字段可以直接关联到marathon的application id，更加直观一些。同时cAdvisor还可以统计一些自定义事件，而我们更多的用日志去收集类似数据，再加上Mesos Exporter也可以统计一些Mesos本身的指标，比如已分配和未分配的资源，所以我们最终选择了Mesos Exporter。 如下图，就是我们监控的部分容器相关指标在Grafana上面的展示： Node exporter，是Prometheus开源的项目，用来收集物理机器上面的各项指标。之前一直使用Zabbix来监控物理机器的各项指标，这次使用NodeExporter+Prometheus主要是出于效率和对于容器生态的支持两方面考虑。时序数据库在监控数据的存储和查询的效率方面较关系数据库的优势确实非常明显，具体展示在Grafana上面如下图： Filebeat是用来替换Logstash-forwarder的日志收集组件，可以收集宿主机上面的各种日志。我们所有的服务都会挂载宿主机的本地路径，每个服务容器的会把自己的GUID写入日志来区分来源。日志经由ElasticSearch汇总之后，聚合的Dashboard我们统一都会放在Grafana上面，具体排查线上问题的时候，会用Kibana去查看日志。 Prometheus配置好了报警之后可以通过AlertManager发送，但是对于报警的聚合的支持还是很弱的。在下一阶段我们会引入一些Message Queue来自己的报警系统，加强对于报警的聚合和处理。 ElastAlert是Yelp的一个Python开源项目，主要的功能是定时轮询ElasticSearch的API来发现是否达到报警的临界值，它的一个特色是预定义了各种报警的类型，比如frequency、change、flatline、cardinality等，非常灵活，也节省了我们很多二次开发的成本。 Read more…