0%

微服务之路

为什么要走微服务

优点

  • 迭代迅速?
  • 适合大企业
  • jira是最好的例子

缺点

  • 开发难度大
    • api向后兼容性: 不同api,还是不同api版本
    • 单元测试覆盖率
    • 如何确定微服务的边界?
  • 要有PAAS层
    • 数据库
    • 中间件
  • devops要求高
    • 自动打包
    • 自动部署
    • 自动生成配置
    • 自动测试
    • 自动上线

我们是怎么做的

自动打包

  • 我们选用了Travis-CI的方案,这个是SAAS服务,只要写好.travis.yml就可以了
    • 支持java等几十种语言
    • 上传到几十种平台
    • 跟github集成
    • 简单的yaml格式编写
  • 代码检查是用的sonar,支持以下功能:
    • 糟糕的复杂度分布:文件、类、方法等,如果复杂度过高将难以改变,这会使得开发人员难以理解它们
    • 重复:sonar可以展示源码中重复严重的地方
    • 缺乏单元测试: sonar可以很方便地统计并展示单元测试覆盖率
    • 没有代码标准: sonar可以通过PMD,CheckStyle,Findbugs等等代码规则检测工具规范代码编写
    • 没有足够的或者过多的注释: 没有注释将使代码可读性变差,特别是当不可避免地出现人员变动时,程序的可读性将大幅下降
    • 潜在的bug: sonar可以通过PMD,CheckStyle,Findbugs等等代码规则检测工具检测出潜在的bug
    • 意大利面式设计: 通过sonar可以找出循环,展示包与包、类与类之间的相互依赖关系,检测耦合, 可以检测自定义的架构规则, 可以利用LCOM4检测单个任务规则的应用情况
  • 包仓库是用的nexus,同时我们还做了一个nexus镜像站点
    • 基于maven的包管理
    • 代理外部maven仓库
    • 管理本地maven仓库
  • docker仓库
    • 基于vmware的harbor
    • 可以进行账号管理
    • 权限分类更细致(支持目录,支持pull和push)

基础平台

  • mesos+marathon
    • mesos作为DC/OS使用
    • mesos对cpu,内存,网络(加patch)限制
    • marathon进行调度
  • PAAS基础
    • 基础资源信息收集Collectd(对比prometheus, ganglia等)
    • 服务metric收集StatsD, Collectd集成了部分StatsD的功能,有些statsd支持的类型不支持
    • influxdb数据存储(历史数据如何保存), sql更好,方便扩展。
    • 日志收集fluentd,优点是方便扩展,第三方插件多,缺点是效率不是很高,处理量大的时候需要起多个进程。
    • redis使用了Mr-redis这种方案。也有redis-cluster这样的方案,但是像codis这样的因为使用blpop和rpush是没法支持的。
    • 服务注册consul, 其他有zk, etcd. cousul的优势是支持多数据中心。Consul通过Gossip协议,完成跨数据中心的同步;而且其他的产品则需要额外的开发工作来实现
    • APIGateway: zuul, kong, istio

开发规范

  • 如何集成服务发现: kce
  • 根据不同环境自动生成配置。
  • 基础组件标准化: redis client, kafka client等
  • 如何查找线上问题的日志:日志格式标准化
  • 服务调度跟踪:pinpoint,zipkin
  • 用户请求跟踪: 每一个请求加入msgid

现有问题

  • elasticsearch,cassandra如何进行paas化?还是没有这个必要先阶段?
  • 波峰波谷的调度?
  • 整体的扩容缩容。