吾之生涯而有限知而无限

在我每次去“每日一本编程书”网站的时候,我就发现几乎过一段时间就会有新的技术书籍出版了,我也会尽快保存下来,尽管我没有及时去看,因为我知道看书是需要时间的,同时就算有时间,你也不一定会去看书,因为看书还需要心境,那种求知的心境,那种甘于寂寞的心境,还有一点就是技术书籍还需要实际去练习的,不仅仅是看完了就是掌握了,最多是了解了,因为很多的知识地掌握需要靠练习,仅仅通过阅读一次就真正掌握是不可能的。

在技术的路上,回归本质,就是到了数据结构和算法,这是最最本质的东西。在本质之外都是一些编程的方法和技巧,还有一些工程的实践。

我在这编程的6年多时间里,绝大多数的编程任务都是对数据进行处理,也就是常说的ACID,几乎所有的编程任务都是围绕这个主题,但是在它的外围体现的是我们对于模拟真正世界的思考,可能会用上一些设计模式,用上一些编程实践,比如测试驱动开发,还有敏捷开发。当然,这满满的都是在后端的基础之上的,前段的编程任务还是负责数据的输入和展示问题。这几年,我写前端的代码时间还是少了很多。

技术一直都在发展,因为总是有新的问题不断地产生和被发现,所以用于解决问题的框架也就多了起来,但是我们把时间花在不断地学习框架上,显然这些投入是将是会不断的过时,比如现在很少会去写JSP页面,因为现在都是前后端分离的框架。同时现在用到Struts2的时间也是少了,因为都是用SpringMVC来完成的,这些Web技术虽然都是过时的,但是对于掌握了其底层的原理来说是极好的,因为新的框架的一项基本功能就是封装以便提供便捷性,也就是编程友好性,当然它也有它的口号——约定优于配置,所以学习的一些成本就是掌握它的一些事先的默认配置。Springboot框架就是其中的典范。

新的技术总是在不断地替代老的技术,总是在不断地更新迭代,SpringCloud项目的发展就可以看到其中的一些端倪。在微服务兴起的那段时间,最早我还去用过Dubbo,最后还是被SpringCloud全家桶所捕获,在Java的生态圈下,或者说是企业级web应用,基本上都没有离开spring框架的领地。

从网关开始,最早的时候还是zuul,后面就是spring cloud gateway。然后就是服务注册和发现—-先是Eureka,后面就是Consul。还有服务的调用,现实Feign,后面又是Open Feign。为了解决服务调用过程中的熔断和降级,之前是Spring Retry,后面又有Resilience4J。甚至过了一段时间Spring Cloud Alibaba三大微服务开发利器问世——Nacos, Sentinel,Seata. 其中Nacos不仅仅解决了服务的注册发现问题,还顺便把服务的配置问题也一块解决了,不然就是之前的Spring Cloud config server那一套。在有些场景之下,分布式事务的引入也是一个不小的挑战,Seata就是其中的利器。在解决无需重启的服务的情况下,配置的更新问题又有了Spring Stream . 当然在它的背后是消息中间件在发挥作用,那时我开始学习Kafka,后来的工作中我又用到了RabbitMQ.在一整套微服务的框架后面又是需要追踪服务的调用链路,很早的时候是hystrix,zipkin ,后面又有sleuth甚至更广的还有Skywalking。还有服务的日志聚合问题,在分布式的环境下之前用的是ELK那一套。同时服务的部署问题也开始引入了Docker, 甚至后面的服务编排——k8s。

这些技术的展开需要花上很久的时间,因为技术一旦深入都是一个个的细节,我们很有可能会错过其中一些。在微服务的开发风行之下,的确服务开发和维护的成本较高,但是面对需要不断市场和业务挑战,这是一个很好的方式,因为事情一旦小,就容易控制风险,也是符合控制变量法的逻辑,这种能快速找到问题的关键,从何发现问题,解决问题或者得出结论。所以这些都是在说明技术产生的原因。

技术的不断更新,也是会带给我们新的认知。在云原生的时代,CNCF是一个新的起点。一切都是在云上,还有infrastructure as code, 基础设施即代码,还有从devops到了gitops时代,新的技术Terraform又是新兴之星。

从整个软件的生命周期而言,我的绝大多数的时间都是在软件的需求分析和设计,编码和测试上后面的部署问题,就基本只是了解一番。我多走了一步,就是学了一番。因为那时我的想法就是在一个小的公司,全才是很重要的竞争力。

在一个大的公司环境,我越来越感受到了全是一件不可取的事情。时间和精力的有限性,在分工明确,合作良好的公司,做好自己本职的工作就是最清醒的认知。

在编程的世界,我之前一直认为我们在从事创作性工作,从无到有,每天的工作内容都是新的,接受的是新的挑战,但是再回归一层就是模拟世界的角度,它不是被创造而不过是模仿,希望模仿还不是拙劣的。

最后的结论,在生涯有限的情况下,学海无涯,我可以做好一件事,认真的做一件事就是极好的。少即是多。业精于勤。

Istio In Action – part two

Part two Securing, observing,and controlling your service’s network traffic

Chapter 4 Istio gateways: Getting traffic into a cluster

4.1 Traffic ingress concepts

4.1.1 Virtual IPs: Simplifying service access

4.1.2 Virtual hosting: Multiple services from a single access point

4.2 Istio ingress gateways

4.2.3 Overall view of traffic flow

4.3 Securing gateway traffic

4.3.3 HTTP traffic with mutual TLS

4.5 Operational tips

Chapter 5 Traffic control: Fine-grained traffic routing

5.1 Reducing the risk of deploying new code

5.1.1 Deployment vs. release

5.2 Routing requests with Istio

5.3 Traffic shifting

5.4 Reducing risk even further: Traffic mirroring

5.5 Routing to services outside your cluster by using Istio’s service discovery

In this chapter, we explored how to reduce the risk of deploying new code by using
traffic mirroring, traffic shifting, and traffic routing to slowly introduce changes to our
users.

In the next chapter, we look at making application interactions more resilient
by implementing timeouts, retries, and circuit breakers.

Istio In Action – part one

Part 1 Understanding Istio

Chapter 1 Introducing the Istio service mesh

1.1 Challenges of going faster

1.1.1 Our cloud infrastructure is not reliable

1.2 Solving these challenges with application libraries

1.3 Pushing these concerns to the infrastructure

1.3.2 Meet the Envoy proxy

1.4 What’s a service mesh?

A service mesh is a distributed application infrastructure that is responsible for handling network traffic on behalf of the application in a transparent, out-of-process manner.

1.5 Introducing the Istio service mesh

1.5.1 How a service mesh relates to an enterprise service bus

1.5.2 How a service mesh relates to an API gateway

1.5.4 Where Istio fits in distributed architectures

Chapter 2 First steps with Istio

2.1 Deploying Istio on Kubernetes

kubectl get nodes

curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.13.0 sh -

istioctl x precheck

istioctl install --set profile=demo -y

kubectl get pod -n istio-system

istioctl verify-install

kubectl apply -f ./samples/addons

2.2 Getting to know the Istio control plane

2.2.1 Istiod

2.2.2 Ingress and egress gateway

2.3 Deploying your first application in the service mesh

2.4 Exploring the power of Istio with resilience,observability, and traffic control

2.4.2 Istio for resiliency

Chapter 3 Istio’s data plane: The Envoy proxy

3.1 What is the Envoy proxy?

3.1.1 Envoy’s core features

  • SERVICE DISCOVERY
  • LOAD BALANCING
  • TRAFFIC AND REQUEST ROUTING
  • TRAFFIC SHIFTING AND SHADOWING CAPABILITIES
  • NETWORK RESILIENCE
  • HTTP/2 AND GRPC
  • OBSERVABILITY WITH METRICS COLLECTION
  • OBSERVABILITY WITH DISTRIBUTED TRACING
  • AUTOMATIC TLS TERMINATION AND ORIGINATION
  • RATE LIMITING
  • EXTENDING ENVOY

3.3 Envoy in action

3.4 How Envoy fits with Istio