ServiceMesh与Istio(一)

近两年微服务架构流行,主流互联网厂商内部都已经微服务化,初创企业虽然技术积淀不行,但也通过各种开源工具拥抱微服务。再加上容器技术赋能,Kubernetes又添了一把火,微服务架构已然成为当前软件架构设计的首选。但微服务化易弄,服务治理难搞! 

微服务的“痛点”

微服务化没有统一标准,多数是进行业务领域垂直切分,业务按一定的粒度划分职责,并形成清晰、职责单一的服务接口,这样每一块规划为一个微服务。微服务之间的通信方案相对成熟,开源领域选择较多的有RPC或RESTful API方案,比如:gRPC、Apache Thrift等。这些方案多偏重于数据如何打包、传输与解包,对服务治理的内容涉及甚少。
微服务治理是头疼的事,也是微服务架构中的痛点。治理这个词有多元含义,很难下达一个精确定义,这里可以像小学二年级学生那样列出治理的诸多近义词:管理、控制、规则、掌控、监督、支配、规定、统治等。对于微服务而言,治理体现在以下诸多方面:

  • 服务注册与发现

  • 身份验证与授权

  • 服务的伸缩控制

  • 反向代理与负载均衡

  • 路由控制

  • 流量切换

  • 日志管理

  • 性能度量、监控与调优

  • 分布式跟踪

  • 过载保护

  • 服务降级

  • 服务部署与版本升级策略支持

  • 错误处理

  • ……

 

从微服务治理角度来说,微服务其实是一个“大系统”,要想将这个大系统全部落地,绝非易事,尤其是之前尚没有一种特别优雅的技术方案。多数方案(比如:Dubbo、go-kit等)都或多或少地对应用逻辑有一定的侵入性,让业务开发人员不能只focus到业务本身,还要关心那些“治理”逻辑。并且市面上内置了微服务治理逻辑的框架较少,且很多编程语言相关。这种情况下,大厂多选择自研或基于某个框架改造,小厂一般只能“东拼西凑”一些“半成品”凑合着使用,就这样微服务也走过了若干年。 Continue reading “ServiceMesh与Istio(一)”

使用kubernetes PodPreset给Pod自动注入信息

参考官方介绍:

https://kubernetes.io/docs/concepts/workloads/pods/podpreset/

https://kubernetes.io/docs/tasks/inject-data-application/podpreset/

激活Pod Preset

Pod Preset目前还是alpha阶段,默认是没有激活的,所以需要通过以下步骤激活:

咱们以阿里云的Kubernetes服务为例(如果还没有,可以尝试一下,一键就可以开通,还免费哦)。阿里云的Kubernetes服务的master组件(API Server, Scheduler, Controller)都是通过Static Pod的方式用Kubelet启动,所以需要更改对应的yaml来激活Pod Preset:

编辑/etc/kubernetes/manifests/kube-apiserver.yaml,

  • 在  -runtime-config 增加  settings.k8s.io/v1alpha1=true
  • 在  --admission-control 增加  - PodPreset

保存后kubelet会自动重启 kube-apiserver组件。我们需要同时更改3台机器的master才可以。

修改Kafka Topic的分区副本数

说明

Kafka提供了一个工具,用于调整Topic中各个分区的复本数据。工具名称叫 kafka-reassign-partitions.sh 。

过程

创建一个Topic,共2个分区,副本数为2(共2份,含原始数据):

查看该Topic。分区0的Leader是1,分区1的Leader是2:

准备一些数据,放在data.file中,然后将数据灌入Kakfa Topic:

在各broker的数据目录下,可以看到当前对应的Topic分区目录:

调整副本数据的配置是以json文件描述的,然后json文件作为参数传递给相关工具。json文件中描述了各个分区的复本如何放置。这里,我们分别为testTopic1的两个分区在原来的基础上新增加了第3个分区。 Continue reading “修改Kafka Topic的分区副本数”

Go继承的属性修改示例

执行后,输出结果为:

 

JWT简介

JWT是一种用于双方之间传递安全信息的简洁的、URL安全的表述性声明规范。JWT作为一个开放的标准(RFC 7519),定义了一种简洁的,自包含的方法用于通信双方之间以Json对象的形式安全的传递信息。因为数字签名的存在,这些信息是可信的,JWT可以使用HMAC算法或者是RSA的公私秘钥对进行签名。简洁(Compact): 可以通过URL,POST参数或者在HTTP header发送,因为数据量小,传输速度也很快
自包含(Self-contained):负载中包含了所有用户所需要的信息,避免了多次查询数据库。

Continue reading “JWT简介”

Go多重继承示例

 

etcd: 从应用场景到实现原理的全方位解读

随着CoreOS和Kubernetes等项目在开源社区日益火热,它们项目中都用到的etcd组件作为一个高可用强一致性的服务发现存储仓库,渐渐为开发人员所关注。在云计算时代,如何让服务快速透明地接入到计算集群中,如何让共享配置信息快速被集群中的所有机器发现,更为重要的是,如何构建这样一套高可用、安全、易于部署以及响应快速的服务集群,已经成为了迫切需要解决的问题。etcd为解决这类问题带来了福音,本文将从etcd的应用场景开始,深入解读etcd的实现方式,以供开发者们更为充分地享用etcd所带来的便利。 Continue reading “etcd: 从应用场景到实现原理的全方位解读”

Kubernetes滚动更新介绍及使用

我们 k8s集群使用的是1.7.7版本的,该版本中官方已经推荐使用 Deployment代替 Replication Controller(rc)了, Deployment继承了rc的全部功能外,还可以查看升级详细进度和状态,当升级出现问题的时候,可以使用回滚操作回滚到指定的版本,每一次对Deployment的操作,都会保存下来,变能方便的进行回滚操作了,另外对于每一次升级都可以随时暂停和启动,拥有多种升级方案: Recreate删除现在的 Pod,重新创建; RollingUpdate滚动升级,逐步替换现有 Pod,对于生产环境的服务升级,显然这是一种最好的方式。 Continue reading “Kubernetes滚动更新介绍及使用”

优化ElasticSearch写入效率

最近在做日志搜集系统,涉及到Kafka到ES的数据解析写入,但是Kafka的写入效率远远高于ES,造成大量的数据在Kafka中积累,且ES的数据更新非常缓慢,最终造成了在Kibana中查询的时候发现,ES中的数据有接近9个小时的数据延迟,这显然是不可接受的。因此,必须着手优化ES的写入效率。在尽可能不改变已有配置的情况下,写入效率优先可以考虑以下两点。

必须使用bulk方式提交写入数据

一开始我们的解析器是通过单条数据的形式提交的数据,很明显这种方式在大数据量的时候就越来越慢,因此我们必须修改为批量提交的方式。ES的bulk提交有个限制就是一次性提交的数据量不能超过15MB,因此,在考虑一次性提交多少条数据比较合适的时候,这个参数无比重要。根据分析,我们目前的数据量一次性bulk提交5000条数据比较合适,约为5-6MB的样子。当然不是越多越好,也不是满满地一定要达到15MB的限制,那样的风险太大,对于我们来讲,能够提升速率满足需求即可。并且我们的程序优化过后能够满足随时根据参数调整bulk请求数量的消息数量大小。我们的k8s中对应的容器配置是这样的:

Continue reading “优化ElasticSearch写入效率”