Microservices do not need to be an independent function or resource like ordinary services. It is perfectly correct to say in the definition that microservices need to match business capabilities. Unfortunately, it still means that if the granularity design of the capability model is wrong, then we have to pay a lot of price. If you read Fowler's entire article, you will find that the guidance is very practical. When deciding to group all components together, developers need to be very confident that they will change and that their size will change. The coarser the service granularity, the harder it is to conform to the prescribed principles. The finer the service granularity, the more flexible it is to reduce the impact of change and load. However, the trade-off process between pros and cons is very complex, and we need to consider the cost of infrastructure on the basis of configuration and funding models.
Next, we demonstrate our microservice project with our k8s
Start replicas themselves are stateless applications without considering the impact of services.
Expansion creates new copies based on the template of the copy itself
replicas are the total number of copies, rather than adding 3 copies to the original base.
[root@k8s-master k8s]# kubectl scale --replicas=3 deployment stock -n ms deployment.extensions/stock scaled [root@k8s-master k8s]# kubectl get pod -n ms NAME READY STATUS RESTARTS AGE eureka-0 1/1 Running 0 21m eureka-1 1/1 Running 0 19m eureka-2 1/1 Running 0 18m gateway 1/1 Running 0 16m gateway 1/1 Running 0 16m order 1/1 Running 0 11m portal 1/1 Running 0 9m31s product 1/1 Running 0 11m stock 1/1 Running 0 6s stock 1/1 Running 0 11m stock 1/1 Running 0 6s
On-line simulation of new functions
Under the product module, here - dev.yml is a local test environment. To modify a function, for example, we need to rebuild the jar package, such as fixing bug s or adding code. We have to rebuild the image, but in k8s, we only need to build a module, no need. Build it all again and go into the branch selection change module. K8s uses a new mirror.
[root@k8s-master simple-microservice-dev3]# vim product-service/product-service-biz/src/main/resources/application-dev.yml
After the development has updated the code and submitted it to the GIT and gitlab repositories, we need git clone to pull the target project code locally.
Then build
[root@k8s-master simple-microservice-dev3]# cd product-service/ [root@k8s-master product-service]# ls pom.xml product-service-api product-service-biz [root@k8s-master product-service]# mvn clean package -D maven.test.skip=true
Why can it be executed in this directory?
[root@k8s-master product-service]# ls pom.xml product-service-api product-service-biz
Because there's this pom.xml here, which describes the dependency packages needed, all of which are defined here.
Then push it to our k8s, execute the script, and it will replace our new module and push the new function up.
The release of new functions of microservices will not affect the use of other modules such as the front end.
[root@k8s-master k8s]# ./docker_build.sh product-service [root@k8s-master k8s]# kubectl get pod -n ms NAME READY STATUS RESTARTS AGE eureka-0 1/1 Running 0 70m eureka-1 1/1 Running 3 69m eureka-2 1/1 Running 3 68m gateway 1/1 Running 0 65m gateway 1/1 Running 0 65m order 1/1 Running 0 60m portal 1/1 Running 0 58m product 1/1 Running 0 115s stock 1/1 Running 0 61m