A Big Boy Blog - Tech Articls & Notes

Kubernetes RocketMQ NameService

发表于 2018-04-17 | 分类于 Kubernetes ， Deployment

单例部署

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nameservice-deployment
  labels:
    app: nameservice
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nameservice
  template:
    metadata:
      labels:
        app: nameservice
    spec:
      containers:
        - image: 
          name: nameservice
          ports:
            - containerPort: 9876
          volumeMounts:
            - name: nameservice-logs-ps
              mountPath: /opt/logs
            - name: nameservice-store-ps
              mountPath: /opt/store
      volumes:
        - name: nameservice-logs-ps
          persistentVolumeClaim:
            claimName: nameservice-logs-pv-claim
        - name: nameservice-store-ps
          persistentVolumeClaim:
            claimName: nameservice-store-pv-claim

集群部署

apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
  name: rocketmq-nameservice
spec:
  serviceName: "rocketmq-nameservice"
  replicas: 2
  template:
    metadata:
      labels:
        app: rocketmq-nameservice
    spec:
      containers:
        - image: 
          name: nameservice
          ports:
            - containerPort: 9876
          volumeMounts:
            - name: nameservice-logs-ps
              mountPath: /opt/logs
            - name: nameservice-store-ps
              mountPath: /opt/store
  volumeClaimTemplates:
    - metadata:
        name: nameservice-logs-ps
      spec:
        accessModes: [ "ReadWriteOnce" ]
        storageClassName: "pd-standard"
        resources:
          requests:
            storage: 5Gi
    - metadata:
         name: nameservice-store-ps
      spec:
        accessModes: [ "ReadWriteOnce" ]
        storageClassName: "pd-standard"
        resources:
          requests:
            storage: 15Gi

kind: StorageClass
apiVersion: storage.k8s.io/v1beta1
metadata:
  name: pd-standard
provisioner: kubernetes.io/gce-pd
reclaimPolicy: Retain
parameters:
  type: pd-standard

查看pv和pvc

1	kubectl get pv / pvc

NAME                                          STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS         AGE
nameservice-logs-ps-rocketmq-nameservice-0    Bound     pvc-584801f4-4208-11e8-90f0-42010a940054   5Gi        RWO            pd-standard          5m
nameservice-logs-ps-rocketmq-nameservice-1    Bound     pvc-6827321f-4208-11e8-90f0-42010a940054   5Gi        RWO            pd-standard          5m
nameservice-store-ps-rocketmq-nameservice-0   Bound     pvc-584866f2-4208-11e8-90f0-42010a940054   15Gi       RWO            pd-standard          5m
nameservice-store-ps-rocketmq-nameservice-1   Bound     pvc-68279d36-4208-11e8-90f0-42010a940054   15Gi       RWO            pd-standard          5m

因为这里使用StorageClass方式，则动态创建PV并绑定PVC

Kubernetes PV/PVC

发表于 2018-04-17 | 分类于 Kubernetes ， Deployment

PV

PVC

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pv-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: pd-standard

使用PVC

volumes:
  - name: nameservice-logs-ps
    persistentVolumeClaim:
      claimName: nameservice-logs-pv-claim
  - name: nameservice-store-ps
    persistentVolumeClaim:
      claimName: nameservice-store-pv-claim

Nginx server_name

发表于 2018-04-16 | 分类于 Server ， Nginx

匹配规则

完全匹配

http {  
    server {  
        listen       80;  
        server_name  test1.com;  
  
        location / {  
            return 500;  
        }  
    }
    server {  
        listen       80;  
        server_name  test2.com;  
  
        location / {  
            return 508;  
        }  
    }  
}

测试命令

curl -i “test1.com/“ -> 查询server_name成功，默认匹配到第1个server，返回500

curl -i “test2.com/“ -> 查询server_name成功，默认匹配到第2个server，返回508

curl -i “test3.com/“ -> 查询server_name失败，默认匹配到第1个server，返回500

禁止非法域名

http {  
    server {  
        listen       80;  
        server_name  test1.com;  
        location / {  
            return 500;  
        }  
    }  
  
    server {  
        listen       80 default_server;  
        server_name  _;  
        return 403;  
    }  
}

测试命令

curl -i “test1.com/“ -> 查询server_name成功，返回500

curl -i “test2.com/“ -> 查询server_name失败，返回403

curl -i “127.0.0.1/“ -> 查询server_name失败，返回403

SSH

发表于 2018-04-15 | 分类于 Linux ， Command

Usage

Change default ssh port

产生一个新的 SSH 密钥对

1	ssh-keygen

更新密钥对的密码

1	ssh-keygen -p

把公钥复制到远程主机上

1	ssh-copy-id -i <identity file> <remote_host>

Kubernetes Affinity

发表于 2018-04-15 | 分类于 Kubernetes

Node

add label to Node

1	kubectl label nodes <node-name> <label-key>=<label-value>

Affinity

亲和性/反亲和性是在Node上设置如何被Scheduler选择的规则一种方式。

必需的规则(Required)

只有满足必需的规则的Pod才会被调度到特定的Node上。如果没有Node匹配条件(加上所有其他所有正常的条件，例如为Pod请求提供足够的可用资源），
否则Pod不会被调度。必需满足的规则在nodeAffinity的requiredDuringSchedulingIgnoredDuringExecution字段中指定。

例如，要求在多可用区域(Multiple Zones)的us-central1-a(GCE)区域中的节点上进行调度

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
        - matchExpressions:
          - key: "failure-domain.beta.kubernetes.io/zone"
            operator: In
            values: ["us-central1-a"]

注意：如果修改为requiredDuringSchedulingRequiredDuringExecution，意味着一旦不满足节点亲和性规则，将从Node上驱逐不再匹配规则的Pod。

首选的规则(Preferred)

首选规则意味着如果节点与规则匹配，则将优先选择它们，并且仅当没有优选节点可用时才选择非优选节点。可以选择使用首选规则，而不是通过必需规则强制将
Pod部署到GCE的us-central1-a区域中的节点上。

使用首选规则，则需指定preferredDuringSchedulingIgnoredDuringExecution：

affinity:
  nodeAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
        - matchExpressions:
          - key: "failure-domain.beta.kubernetes.io/zone"
            operator: In
            values: ["us-central1-a"]

AntiAffinity

Node的反亲和性能够使用负操作符(NotIn, DoesNotExist等)来表示。

例如，禁止Pod被调度到us-central1-a的区域中

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: "failur-domain.beta.kubernetes.io/zone"
          operator: NotIn
          values: ["us-central1-a"]

Taints and Tolerations

此功能允许您标记一个Node(“受污染”，“有污点”），以便没有Pod可以被调度到此节点上，除非Pod明确地“容忍”污点。
标记的是Node而不是Pod（如节点的亲和性和反亲和性），对于集群中大多数Pod应该避免调度到特定的节点上的功能特别有用。

例如，您可能希望主节点（Master）标记为仅可调度Kubernetes系统组件，或将一组节点专用于特定的用户组，或者让常规的
Pod远离具有特殊硬件的Node，以便为有特殊硬件需求的Pod留出空间。

设置Node的Taints

1	kubectl taint nodes node1 key=value:NoSchedule

创建一个污点并标记到Node，那些没有设置容忍的Pod，不能调度到该Node上。其他污点的选项是PerferredNoSchedule，这是NoSchedule首选版本。

NoExecute，这个选项意味着在当Node被标记有污点时，该Node上运行的任何没有设置容忍的Pod都将被驱逐。容忍将被添加到PodSpec中，看起来像这样：

tolerations: 
  - key: "key"
    operator: "Equal"
    value: "value"
    effect: "NoSchedule"

除了将污点和容忍(Taints and Tolerations)特性在Kubernetes 1.6中移至Beta版外，我们还引入了一个使用污点和容忍的Alpha的特性：
允许用户自定义一个Pod被绑定到Node上后遇到了诸如网络分区的问题时的行为（可能Pod希望长时间允许在这个Node上，或者网络分区会很快恢复），
而不是现在默认的等待五分钟超时。

Pod

Affinity

部署到指定label的node

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  nodeSelector:
    disktype: ssd

pod只会调度到具有disktype=ssd的node上面

AntiAffinity

dig

发表于 2018-04-15 | 分类于 Linux ， Command

安装

1	sudo pacman -S dnsutils

使用制定DNS解析域名

1	dig @1.1.1.1 +short lax-dgc.savoy.click

Spring Boot Token Filter

发表于 2018-04-15 | 分类于 Server ， SpringBoot ， Filter

add filter

@Bean
fun getJwtFilter(): FilterRegistrationBean {
    val filterBean = FilterRegistrationBean()
    filterBean.filter = JwtFilter()
    val including = appProperties.filter?.jwt?.include?.split(",")
    including?.forEach { it -> filterBean.addUrlPatterns(it) }
    return filterBean
}

filter config

@Component
class JwtFilter : GenericFilterBean() {
    private val log: Logger = LoggerFactory.getLogger(JwtFilter::class.java.simpleName)
    private val methods = arrayListOf(RequestMethod.GET.name, RequestMethod.POST.name, RequestMethod.PUT.name, RequestMethod.DELETE.name)

    override fun doFilter(servletRequest: ServletRequest?, servletResponse: ServletResponse?,
                          filterChain: FilterChain?) {
        val request = servletRequest as HttpServletRequest
        val response = servletResponse as HttpServletResponse
        val path = request.requestURI.substring(request.contextPath.length).replace("[/]+$", "")
        log.debug("doFilter(): path:$path")
        if (methods.contains(request.method)) {
            if (!FilterConfig.JwtExcludePath.containsKey(path)) {
                val token = request.getHeader(AuthConfig.TokenHeader)
                if (!JwtUtil.isValid(token, KeyConfig.publicKey)) {
                    response.sendError(401)
                    return
                }
            }
        }
        filterChain?.doFilter(request, response)
    }
}

浅析 MVC MVP 与 MVVM之间的异同

发表于 2018-04-15 | 分类于 CS

http://wzhscript.com/2015/02/03/mvc-mvp-and-mvvm/

TDD，BDD，DDD 三者的区别

发表于 2018-04-15 | 分类于 CS

TDD

测试驱动开发（英语：Test-driven development，缩写为TDD）是一种软件开发过程中的应用方法，由极限编程中倡导，以其倡导先写测试程序，
然后编码实现其功能得名。

测试驱动开发始于20世纪90年代。测试驱动开发的目的是取得快速反馈并使用“illustrate the main line”方法来构建程序。

测试驱动开发是戴两顶帽子思考的开发方式：先戴上实现功能的帽子，在测试的辅助下，快速实现其功能；再戴上重构的帽子，在测试的保护下，通过去除冗余的代码，提高代码质量。测试驱动着整个开发过程：首先，驱动代码的设计和功能的实现；其后，驱动代码的再设计和重构。

实践

优点

可以有效的避免过度设计带来的浪费。但是也有人强调在开发前需要有完整的设计再实施可以有效的避免重构带来的浪费。
可以让开发者在开发中拥有更全面的视角。

缺点

开发者可能只完成满足了测试的代码，而忽略了对实际需求的实现。有实践者认为用结对编程的方式可以有效的避免这个问题。
会放慢开发实际代码的速度，特别对于要求开发速度的原型开发造成不利。这里需要考虑开发速度需要包含功能和品质两个方面，单纯的代码速度可能不能完全代表开发速度。
对于GUI,资料库和Web应用而言。构造单元测试比较困难，如果强行构造单元测试，反而给维护带来额外的工作量。有开发者认为这个是由于设计方法，而不是开发方法造成的困难。
使得开发更为关注用例和测试案例，而不是设计本身。目前，对于这个观点有较多的争议。
测试驱动开发会导致单元测试的覆盖度不够，比如可能缺乏边界测试。在实际的操作中，和非测试驱动开发一样，当代码完成以后还是需要补充单元测试，提高测试的覆盖度。

BDD

行为驱动开发（英语：Behavior-driven development，缩写BDD）是一种敏捷软件开发的技术，它鼓励软件项目中的开发者、
QA和非技术人员或商业参与者之间的协作。

BDD的重点是通过与利益相关者的讨论取得对预期的软件行为的清醒认识。它通过用自然语言书写非程序员可读的测试用例扩展了测试驱动开发方法。

行为驱动开发人员使用混合了领域中统一的语言的母语语言来描述他们的代码的目的。这让开发者得以把精力集中在代码应该怎么写，而不是技术细节上，
而且也最大程度的减少了将代码编写者的技术语言与商业客户、用户、利益相关者、项目管理者等的领域语言之间来回翻译的代价。

实践

确立不同利益相关者要实现的远景目标
使用特性注入方法绘制出达到这些目标所需要的特性
通过由外及内的软件开发方法，把涉及到的利益相关者融入到实现的过程中
使用例子来描述应用程序的行为或代码的每个单元
通过自动运行这些例子，提供快速反馈，进行回归测试
使用“应当(should)”来描述软件的行为，以帮助阐明代码的职责，以及回答对该软件的功能性的质疑
使用“确保(ensure)”来描述软件的职责，以把代码本身的效用与其他单元(element)代码带来的边际效用中区分出来。
使用mock作为还未编写的相关代码模块的替身

DDD

领域模型（或称域模型；英语：domain model）可以被看作是一个系统的概念模型，用于以可视化的形式描述系统中的各个实体及其之间的关系。
领域模型记录了一个系统中的关键概念和词汇表，显示出了系统中的主要实体之间的关系，并确定了它们的重要的方法和属性。因此，对应于用例所
描述的动态视图，领域模型提供了一种对整个系统的结构化的视图。领域模型的一个好处是描述并限制了系统边界。

领域模型的语义可以被用在源代码中，因此领域模型可以被应用在底层的软件开发阶段中。实体可以演化为类，方法和属性可以直接演化至代码之中。
在UML中，类图被用来描述领域模型。

Spring Boot Exception

发表于 2018-04-13 | 分类于 SpringBoot

capture exception

Jason - sulang357159@163.com

RSS