DevilKing's blog

国庆期间，又把逃避看了一遍，果然电视里都是美好的，big happy ending

不过现实还是现实，能混一个not bad ending就不错了，嗯，目标是not bad ending，经历过，not bad就好了

抱着这样的目标，保持一些独立性，保持一点进步性，战战兢兢，安安静静地做好自己的acer

不是有职业单身汉这个职业，安稳，不变化，或者说一切的变化都在自己的承受范围内

不要各种自以为是的地要求他人，也就是狂妄吧，自卑地把声音放低，不要强调自己的声音。。。

没有女性经验，但也有很好的结局，毕竟是电视，现实的话，只能呵呵，或许是自己的肾不好，存不住水。。哈哈。。

也无所谓了，有了觉悟了，也就是觉得尴尬，其实也没什么，相比之下，只是痛苦一些，也没啥了

为了not bad的结局，嗯，加强自己的学习和锻炼啥的，每周去总结自己的不足，每周养成一点小好的习惯，改正一些不好的习惯。。。

电视里最后还是勇敢面对了，不过那还是电视，现实上还是能逃避一会儿是一会儿吧，能活下来就好，对，不管是怎样的方式，活下来就好。。。活下来，见识一下就好。。。

一个人有两个人的心态。。。哈哈。。。

頑張って！

原文链接

• vtgate 可以认为是网关,client 只需要与vtgate 连接即可，vtgate 会把相应的sql 路由到相应的vttablet 进行查询 执行等，vtgate 可以启动多个，来做负载均衡，相当于proxy部分
• vttablet 可以认为是在mysql 前面挡了一层，一个vttablet 对应一个mysql 实例，主要提供连接池、查询重写、查询去重、以及相应的管理操作
• vtctl 命令行， 提供管理vitess 的命令等，包括查询master-slave关系，sharding 信息。例如，建表，执行sharding resharding ，执行failover(切换主从关系等)等操作。
• vtworker 执行一些需要长时间运行的进程。它支持一个插件式的架构并提供了第三方库，这样你可以轻易选择要使用的 tablet。该插件可以用于以下类型的工作：
  • resharding differ：在水平分片的分割以及合并时核查数据完整性的工作
  • vertical split differ：在垂直分割以及合并时核查数据完整性的工作
  • vtworker 还允许您轻松地添加其他验证程序。你可以进行 in-tablet 完整性检查以验证外键之类的关联关系或者跨片完整性检查，例如，一个密钥空间里的索引表所指向的数据在另一个密钥空间里。

Vitess 使用基于范围的分片。Vitess 使用一个数据存储一致性的拓扑支持，比如 etcd 或者 ZooKeeper。这也就意味着集群视图始终是最新的而且对于不同的客户端也能始终保证其一致性。

Keyspace对应着mysql逻辑上的一个database，那么他的关键的就是做sharding，还有作为读写分离部分

一个tablet 包含

1. 一个mysql instance
2. 一个 vttablet instance
3. 一个可选的row cache instance (memcache)
4. 其他一些特定的database 相关进程

类型

1. master 主库
2. replica 低延迟的从库
3. rdonly 延迟相对较高的只读库，主要执行一些后台耗时操作
4. spare 暂时不工作的slave

原文链接

不想使用protobuf，使用gRPC，可以采用gRPC+JSON的方式

本文中采用Gson的方式

grpc vs thrift vs pyrc

rpc框架逃离不出，配置文件的束缚？那在形成python lib的时候，是否要总是使用最新的配置文件去生成？感觉也是可行的，按照版本来行，thrift部分，可以通过不同的版本，逐次地开放更多的功能这样子？

My preferences are:

• I would personally perfer to use RPyC if python is the only language I am going to use.
• I would prefer to use gPRC if I needed robustness, reliability, and scalability from my services.
• The best thing about Thrift is that it supports so many languages. If that’s what you’re targetting, go for Thirft.

grpc部分的配置文件，需要重新生成这样子？

原文链接

elb做load balancer

服务发现

• SmartStack，对象存储，依赖zookeeper来存储发现数据
• Nerve 管理微服务的生命周期
• Synapse，服务发现，并更新haproxy
• meta信息部分，存储到zookeeper部分

Infrastructure

配置管理部分，采用Chef

数据仓库部分

microservices

后端采用Dropwizard 框架，并发布为Thrift IDL

search services

Nebula is a schema-less, versioned data store service with both real-time random data access and offline batch data management

原文链接

Kubernetes ingress is a collection of routing rules that govern how external users access services running in a Kubernetes cluster.

Ingress in Kubernetes

• Using a Kubernetes service of type NodePort, which exposes the application on a port across each of your nodes
• Use a Kubernetes service of type LoadBalancer, which creates an external load balancer that points to a Kubernetes service in your cluster
• Use a Kubernetes Ingress Resource

nodePort与service部分绑定，无关node部分，

This external load balancer is associated with a specific IP address and routes external traffic to a Kubernetes service in your cluster.

Typically, though, your Kubernetes services will impose additional requirements on your ingress. Examples of this include:

• content-based routing, e.g., routing based on HTTP method, request headers, or other properties of the specific request
• resilience, e.g., rate limiting, timeouts
• support for multiple protocols, e.g., WebSockets or gRPC
• authentication

用ingress，扩展来说，可以说是service mesh？应该是可以实现每一个部分？通过ingress controller部分来实现

Different ingress controllers will have different functionality, just like API Gateways. Here are a few choices to consider:

• There are three different NGINX ingress controllers, with different feature sets and functionality.
• Traefik can also be deployed as an ingress controller, and exposes a subset of its functionality through Kubernetes annotations.
• Kong is a popular open source API gateway built on NGINX. However, because it supports many infrastructure platforms, it isn’t optimized for Kubernetes. For example, Kong requires a database, when Kubernetes provides an excellent persistent data store in etcd. Kong also is configured via REST, while Kubernetes embraces declarative configuration management.
• Ambassador is built on the Envoy Proxy, and exposes a rich set of configuration options for your services, as well as support for external authentication services.