Foreword
Hello, everyone, for a long time did not write a blog, the past six months is relatively busy, so give attention to my fans an apology. Big Brother last year and Zhu Yongguang talk when we raised about this program, he said let me free to write a blog to talk about before is very busy, so this time to take advantage of some of what we write here about version control the program now.
So today we are to share a use of a solution based on WebApi k8s kong gateway and management of multiple versions, this program has been running in our production environment for nearly two years, but also a lot of iterative versions, we feel that this program very suitable for use in micro among service.
What is WebApi multiple versions
Version of the concept we should all know, then what is WebApi version of it?
App developers should backend brothers are very clear, in time to provide WebApi App interface, due to the presence of multiple App client version is installed on the user's cell phone issue, most of the time these versions need to co-exist, due to the now Android and IOS App built basically not allowed to upgrade features, of course, there are times when the user is unwilling or decline an upgrade, a lot of time in the constantly changing business needs, can not be avoided to adjust the interface and adding new features, so we need to ensure that the back-end forward compatibility interface, customers who do not upgrade them to make ends App still working properly, which requires the use of several different versions of Api interface for control, many times we are to retain the old interface to add new interfaces, to distinguish between different clients, then the version number to the interface, which is more WebApi version control management.
Scenarios
After understanding the concept of WebApi multiple versions, application scenarios will naturally understand.
In addition to the server after the App will be used, also applies to those serving non-browser client-side projects, such as providing an interface to a number of desktop applications and so on.
Sometimes different features for App client is one scene of some of the features of its application.
solution
App solution is to carry a version of the information at the time of the request to the server, then the server will be able to provide the different functions.
Api request to the server can carry version information in two ways:
- By adding a version number in the URL or as a query string parameter.
- By Http custom headers.
In ASP.NET Core Solution
In ASP.NET Core of the program, I do not intend to detail, and interested can look below the big brother of this article:
Pineapple blowing snow -Code: the ASP.Net Core WebApi several versioning
Based K8s Kong and solutions
Since we are using is based on multiple versions solutions Kubernetes, so here will explain in detail.
We use version control in the URL is added to the version number to achieve, this has two advantages:
1, to facilitate kong routing resolution can be achieved directly through the configuration, if routed through the header, it needs its own to expand the job.
2, from time logging can be very intuitive to see the current version of the API, the specific version when a problem occurs can quickly locate service.
Here is one of our Kubernets generally based architecture diagram I drew, like those I gave CDN missed.
The main process is divided into the following steps:
1, different versions of App end Api request interfaces, these interfaces Api to distinguish versions, different versions may provide different results.
2, Kong gateway for the version number information URL carried in the routing forward, we need to carry path parameters open when configuring routing forwarding, such as /api/v1/ordering/listthe request address, we can create a new route, then configure /api/v1/orderingURL prefix forwarded to ordering the service, while the path with the past, if that address our ordering service for micro /api/orderingpath, then you can configure the service is /api/orderingdue to the carry path routing configuration, so this time we micro service requests received address becomes a /api/ordering/list.
3, Kong gateway to NodePort Kubernets deployed to the cluster, the cluster routing service point dns address Kubernets internal services. Examples Kong plurality of configuration information is shared between them, you can be configured to store in PostgreSql or Cassandra.
4, the internal back-end micro-services cluster provides cluster address configuration Kong to the Service.
With business needs
This whole scenario there is an important point is a developer and product or service personnel with the problem, that is, the entire development process in line with the progress of the plan requires agile development, this will not lead to every little version will have a very big change the emergence of this demand interface, you can do a smooth upgrade.
In my example to the Secretary, when there needs to be major changes in the interface, we will plan to release a large main iteration, so that when the big release, it will play a big new version of the service to a clustered environment be supported at this time still does not remove the old version, so old and new versions will co-exist at the same time, when a new version re-iteration of a few minor version when in fact the majority of users have been automatically rise up, and this time you can put a big old mandatory upgrade version suggests, this will all end App users upgrade to the new version, and thus to reduce the impact to a minimum.
So, here follows a principle: do small version compatible upgrade, do provide a large version of the code refactoring and Break Changes and major characteristics of the work.
DevOps fit
When making major version upgrade, DevOps micro-services infrastructure is very important, then we need to create a dynamic routing kong, which requires the use with DevOps, you can create the rest of the interface to provide call kong create a route, maybe a start will take more time, but in the long term, then it is very important, it can save a lot of follow-up time.
In my example to the Secretary, when the major version upgrade, DevOps script detects the version number for the large version, then it will run the script to create a new environment, this script is responsible for initializing new major version of k8s cluster environment and kong service and routing configuration, then automatically release a new version of each service will eventually provide a new service address out of it, similar to the / api / v2 / xxxx
With data services middleware
The new version of the development process of large and iteration is performed, will be involved in some cases data about the new version and the old version are not compatible, such as Redis cache data structure changes, changes in the data structure of the message queue, and so on Elasticsearch index changes in the data structure.
So how do you handle more data services version compatible problem? The simplest solution is to play a new environment, a new version of the full use of a new set of middleware services environment to run, but this has a drawback that uses more server resources, according to the server to waste resources, of course, if the company can ignore the local tyrant.
That if you want to use different versions of the same data middleware services how to do it? In fact, is there a way, most of the data are all supported versions of middleware division, such as Elasticsearch, CAP and so support the use of data to distinguish between versions, do not support can be controlled in the program, such as Redis this can DB used to distinguish different logic.
to sum up
This article focuses on the question if the use of gateways and k8s kong webapi service to handle multiple versions.
It also describes how some of the different versions of the data should be handled and planning needs in the development process, I hope something can help to people in need.
If you think this article helpful to you, then, thank you for your [Recommended].
If you are interested in .NET Core, then you can follow me, I regularly share my learning experience in a blog.
This article addresses: http://www.cnblogs.com/savorboard/p/webapi-versions.html
of the blog: Savorboard
paper original authorized: Attribution - Noncommercial - No Derivative agreement plain text | Protocol legal texts