微服务之路
为什么要走微服务
优点
- 迭代迅速？
- 适合大企业
- 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化？还是没有这个必要先阶段？
- 波峰波谷的调度？
- 整体的扩容缩容。