Foreword
Since 2013 containers (virtual) technology (Docker) mature, the back-end architectural approach to enter the stage of rapid iteration, there have been many new concepts:
- Micro Services
- k8s
- Serverless
- IaaS: Infrastructure Services, Infrastructure-as-a-service
- PaaS: Platform Services, Platform-as-a-service
- SaaS: Software services, Software-as-a-service
- Cloud Native: Native Cloud
- Service Mesh
Changes and development of cloud computing is closely related to the back-end architecture, architecture in fact constantly adapt to cloud computing, especially the native cloud, known as the architecture of the future, in 2019, cloud native floor plan Service Mesh full bloom at home and abroad, I We believe that the future has come.
Next, we will:
- Carding back-end architecture evolution history, recalling the backend infrastructure development;
- Recalling the development of cloud services, cloud explore the native concept;
- Carding native cloud development programs to achieve the Service Mesh;
- Introduction Service Mesh representative Istio rosy function;
Back-end architecture evolution history
Centralized architecture
Centralized architecture known as unibody architecture, very popular in the Web2.0 model is not a large-scale rise. Later, B Web-based applications / S (Browser / Server) architecture gradually replacing desktop-based application of C / S (Client / Server) architecture. B / S structure of the back-end systems were powered by a centralized architecture, it was an elegant layered design, unified development areas of the back-end server.
Centralized application into a standard three-tier structure model: data access layer M, and a logic control service layer V layer C. FIELD model objects may be shared between each of the layers may also be more finely resolved.
The disadvantage is that
- Compilation time;
- Regression test cycle is too long;
- Development efficiency and decreased;
- Is not conducive to update the technical framework
Distributed System Architecture
For the rapid growth of Internet applications scale, centralized architecture of unlimited and can not be done to enhance the throughput of the system, and distributed system architecture provides a theoretically unlimited expansion possibilities for increased throughput. Therefore, the server used to build Internet applications has gradually abandoned the costly minicomputer in favor of a large number of cheap PC servers.
Docker container technology a new era
The concept of distributed architecture appeared very early, the biggest problem hindering its landing container is immature technology, applications running in the cloud platform, still need to install the runtime environment for different development languages. Although the operation and maintenance of automation tools can reduce the complexity of setting up the environment, but the environment is still not solve the problem fundamentally.
Docker appeared to be a new watershed in the software development industry; mature container technology, also marks a new era of open technology. Docker is allowing development engineers rely on their applications and can be packaged into a portable container. Just as the emergence of smart phones has changed the rules of the game, like the mobile phone industry, Docker also a great swept through the software industry, and in turn change the rules of the game industry trends. By applying containerized package, development, and operation and maintenance are issued in a standardized way, heterogeneous language is no longer a team shackles shackles.
After Docker, micro service to catch on
Micro Services Architecture
Micro-service architecture style is a way to develop a single application for a group of small service method, each service runs in its own process, the inter-service communication using lightweight communication mechanism (usually HTTP resource API). These services build around business capabilities and can be deployed independently by automatic deployment mechanism. These services are the most common small centralized management services developed in different languages available, using different data storage technologies.
Micro Advantage Service
- Scalable
- Scalable
- Easy to maintain
- Fault isolation and resource
The problem of micro-services
However, there is no perfect thing in the world, micro-services as well. Well-known software guru, Chris Richardson is considered one of the top ten software architect has sharply pointed out: "micro-service applications are distributed systems, which will bring the complexities inherent in the developer needs to be passed in the RPC or message. selectin and complete inter-process communication mechanism. in addition, they have to write code to handle messaging is slow or unavailable local failure and other problems. "
In the micro-service architecture, in general, to deal with the following types of questions:
- Service Governance: resilient and elastic, fault isolation
- Flow control: routing, fuse, speed limit
- Application of observation: measurement index, chain track
Solution Spring Cloud (Netflix OSS)
This is a typical micro-service architecture diagram
Spring Cloud system provides service discovery, load balancing, failover, dynamic expansion and data partitioning, call the central function link monitoring distributed systems, it became the best practices of micro-services.
Spring Cloud problem
If you start building method micro services, certainly easy to be attracted to Netflix OSS / Java / Spring / SpringCloud. But to know that you are not Netflix, does not require direct use of AWS EC2, it makes the application becomes very complicated. Today, the use of docker and adopt memos / kubernetes be wise, they already have a large number of distributed system characteristics. Layering at the application layer, because the problem faced by netflix 5 years ago, but had to do it (if it can be said that time had kubernetes, netflix OSS stack will be very different).
It is therefore recommended careful selection, on-demand options, to avoid the application of unnecessary complexity.
Indeed SpringCloud program looks very nice, but it has a very strong intrusive, application code will contain a large number of SpringCloud module, but also to other programming languages is not friendly.
Kubernetes
Kubernetes SpringCloud appears to solve problems, not to invade the application layer, to solve the problem in a container layer.
Kubernetes origin
Kubernetes originally from Borg internal Google provides a container cluster deployment and management of application-oriented systems.
Kubernetes targets aimed at eliminating the burden of scheduling physical / virtual computing, networking and storage infrastructure, applications and operators and developers to fully focus on container-centric self-service primitives operations.
Kubernetes also provide a stable, compatible base (platform) for building customized workflows and more advanced automation tasks. Kubernetes have improved cluster management capabilities, including multi-level security and access mechanism, multi-tenant application support capabilities, transparent service registration and service discovery mechanism, built-in load balancing, fault finding and self-healing capabilities, service rolling upgrade and online capacity expansion, scalable automatic resource scheduling mechanism, resource quota management capabilities and more granularity.
Kubernetes also provide comprehensive management tool, covering the development, deployment, testing, operation and maintenance monitoring and other links.
Service Mesh
Service Mesh is an enhancement to Kubernetes, providing more capacity.
September 1, 2018, Bilgin Ibryam on InfoQ published an article Microservices in A Post-Kubernetes Era , see below Chinese version of the micro-services Kubernetes era (some translation errors, for reference only).
This paper is the author's point of view: After Kubernetes era, service grid (Service Mesh) technology has completely replaced the way to use software libraries for network operation and maintenance (eg Hystrix breaker) is.
If Kubernetes of Spring Cloud fired the first shot, then the Service Mesh is Spring Terminator Cloud's.
to sum up
Finally, we use a flow chart to describe the development of back-end architecture
Probably schedule each critical node
| Architecture / Technology | Time / Year |
|---|---|
| Centralized architecture | ~ |
| Distributed Architecture | ~ |
| Docker | 2013 |
| Micro Services | 2014 |
| Spring Cloud | 2014 |
| Kubernetes mature | 2017 |
| Service Mesh | 2017 |
As can be seen, micro-ecological service here, Spring Cloud as the representative of this road has no heir, the future belongs to Service Mesh.
Service Mesh after two years of development, Service Mesh mature enough, there have been cases of the production floor, we are going to look at Service Mesh, before that, we must first understand a concept, cloud native.
Cloud Cloud Native Native
How to understand the "cloud native"? The reason why this topic on the front, because this is the most basic understanding of the concept of native cloud, which will directly affect all subsequent cognitive.
Note: The following native cloud content all references Ao small sword talk about cloud native (on): Cloud native application should look like? This article, drawing too well.
Define cloud native has been in development, each person's understanding of native cloud may be different, as Shakespeare put it: a thousand eyes of a thousand Hamlet.
2018 CNCF ( Cloud Computing Foundation Native ) updated the definition of cloud-native.
This technology represents the new definition described, wherein the container and micro-services have appeared in two different definitions in different periods, but this service grid in 2017 began to be accepted by the community to be very eye-catching new hot technology column out, and micro-services side by side, rather than what we usually think of the service grid only slightly services in a new way at the time of implementation.
How do we understand cloud native it? We try, the Cloud Native apart to understand this term, take a look at what is Cloud.
What is Cloud Cloud
Quick look at the history of cloud computing to help us have a more emotional understanding of the cloud.
Closely related to the emergence of virtualization technology and the development and maturity of cloud computing, after the year 2000 x86 virtual machine technology is mature, cloud computing gradually developed.
Based on virtual machine technology, it has been found in the form of IaaS / PaaS / FaaS, as well as their open source version.
2013 docker appears, container technology is mature, then a war around the container layout, and finally at the end of 2017, kubernetes win. CNCF founded in 2015, and formed a cloud native ecology in recent years.
In this process, cloud formations have been changed, you can see: suppliers more and more functions, and the customer or application needs fewer and fewer own management.
Architecture also has to adapt to changes in cloud computing
What is Native Native
After complete review of the history of cloud computing, we have a better understanding of the Cloud, and then continue to look at: What is Native?
Dictionary explanation is: innate.
That Cloud and native and together, how to understand?
Here we throw one of our own understanding: cloud native represents the native cloud design. Detailed explanation is: the native application is designed to work optimally in the cloud, give full play to the advantages of the cloud.
这个理解有点空泛，但是考虑到云原生的定义和特征在这些年间不停的变化，以及完全可以预料到的在未来的必然变化，我觉得，对云原生的理解似乎也只能回到云原生的出发点，而不是如何具体实现。
Cloud Native 是道，Service Mesh 是术
那在这么一个云原生理解的背景下，我再来介绍一下我对云原生应用的设想，也就是我觉得云原生应用应该是什么样子。
在云原生之前，底层平台负责向上提供基本运行资源。而应用需要满足业务需求和非业务需求，为了更好的代码复用，通用型好的非业务需求的实现往往会以类库和开发框架的方式提供，另外在 SOA/ 微服务时代部分功能会以后端服务的方式存在，这样在应用中就被简化为对其客户端的调用代码。
然后应用将这些功能，连同自身的业务实现代码，一起打包。
而云的出现，可以在提供各种资源之外，还提供各种能力，从而帮助应用，使得应用可以专注于业务需求的实现。
非业务需求相关的功能都被移到云，或者说基础设施中去了，以及下沉到基础设施的中间件。
以服务间通讯为例：需要实现上面列举的各种功能。
SDK 的思路：在应用层添加一个胖客户端，在这个客户端中实现各种功能。
Service Mesh 的思路，体现在将 SDK 客户端的功能剥离出来，放到 Sidecar 中。就是把更多的事情下沉，下沉到基础设施中。
在用户看来，应用长这样：
云原生是我们的目标，Service Mesh 交出了自己的答卷，接下来我们可以回到 Service Mesh 这里了。
Service Mesh
其中文译名是服务网格，这个词最早使用由开发Linkerd的Buoyant公司提出，并在内部使用。
定义
服务网格的基本构成
纷争 2017
2017 年年底，当非侵入式的 Service Mesh 技术终于从萌芽到走向了成熟，当 Istio/Conduit 横空出世，人们才惊觉：微服务并非只有侵入式一种玩法，更不是 Spring Cloud 的独角戏！
解读 2017 之 Service Mesh：群雄逐鹿烽烟起
文章总结一下：
创业公司 Buoyant 的产品 Linkerd 开局拿下一血；
Envoy 默默耕耘；
从 Google 和 IBM 联手推出 Istio，Linkerd 急转直下；
2017 年底 Buoyant 推出 Conduit 背水一战；
Nginmesh 与 Kong 低调参与；
百家争鸣 2018
2018 年，Service Mesh 又多了哪些内容呢？在 2018 年，Service Mesh 在国内大热，有多家公司推出自己的 Service Mesh 产品和方案，Service Mesh 更加热闹了。
详细见这篇文章 下一代微服务！Service Mesh 2018 年度总结
文章总结一下：
Service Mesh 在国内大热，有多家公司加入战场；
Istio 发布1.0，成为最受欢迎的 Service Mesh 项目，获得多方支持；
Envoy 继续稳扎稳打，Envoy 被 Istio 直接采用为数据平面，有望成为数据平面标准；
Linkerd1.x 陷入困境，Conduit 小步快跑，但响应平平，Buoyant 公司决定合并产品线，Linkerd1.x + Conduit = Linkerd2.0；
更多的公司参与 Service Mesh，国外有 Nginx、Consul、Kong、AWS等，国内有蚂蚁金服、新浪微博、华为，阿里 Dubbo，腾讯等；
持续发展 2019
2019 将会听到更多 Service Mesh 的声音，请关注Service Mesh 中文社区
Istio
前文讲到 Istio 是当前最受欢迎的 Service Mesh 框架，一句话定义 Istio：一个用来连接、管理和保护微服务的开放平台。
它能给我们的微服务提供哪些功能呢？
连接
- 动态路由
- 超时重试
- 熔断
- 故障注入
保护
安全问题一开始就要做好，在 Istio 实现安全通讯是非常方便的。
Istio 支持双向 TLS 加密
控制
速率限制
黑白名单
观测
-
指标度量：每秒请求数，Prometheus 与 Grafana
使用 Grafana 观测流量情况
-
分布式追踪：Jaeger 或 Zipkin
快速观测调用链路
-
日志：非应用日志
-
网格可视化
快速理清服务的关系
总结
虚拟化技术推动这云计算技术的变革，顺带也影响了后端架构的演进，目前我们身处云时代，将会有更多的元原生应用出现，Istio 作为其中的佼佼者，值得你投入一份精力了解一下。