Article Directory
Summary
Today, finally have free time point, the update bit code generator, user feedback bug fixes, this update mainly adds dubbo and springcloud scaffolding download, shelves are personally set up to facilitate the expansion of freedom or white learning use, you might ask why they can not be generated by the same way as springboot configuration of the project, I can only answer: theoretically possible, since there will be time to explore feasible way, but I think the micro-business complex services framework, easy to use free as a direct extension to the scaffolding, so now is the use of such a method. This blog describes the specific function of each part of the scaffolding module, then Imagine what the future development trend of micro-services technology.
dubbo scaffolding
dubbo was all the rage, but gradually springcloud replaced, so I do dubbo scaffolding is relatively simple to watch nostalgia.
Code generator get dubbo scaffolding is very simple, as follows:
mouse click can be automatically downloaded to your desktop
and then look at the directory structure of scaffolding:
project into the idea of them, because dubbo need zookeeper dependent, so you need to configure zookeeper registry, I believe you can themselves -
specific details, please refer to my dubbo + zookeeper contrast springCloud and distributed Detailed project to build on this blog, this blog is the scaffolding which tells the demo project.
springcloud scaffolding
The scaffold springcloud idea downloaded into them, project structure as follows:
The following briefly explain the configuration of each module, the reader may use other details generator download their own view.
cloud_eureka module
This module is mainly responsible for the registration service discovery, the equivalent of dubbo the zookeeper, but springCloud to use eureka discovery and registration services, I believe we all know that CAP principles, namely consistency, availability and fault tolerance partitions, as long as the project is distributed, usually have a fault tolerant partition (simple appreciated hanging a node, the other node can provide normal service).
zookeeper itself is not designed for the high availability of the data between the nodes can maintain a high degree of synchronization, and once isolated from the network occurs, the interior will be zookeeper master election, this selection process is very slow, up to 30 to 120 seconds, for a system to continue to provide services to the outside world, it will be very deadly! So dubbo + zookeeper Overall, in line with the principles of CP.
springcloud of service registry is different eureka, eureka each node is equal, there will be no elections master node with that, and itself has a self-protection mechanism, highly available services, relative, it can not do data strong agreement, which is not guaranteed to always get on each node are the latest data, but we can guarantee the consistency of the final result at the time of programming. So springcloud Overall, in line with the principles of AP.
Let's look at cloud_eureka of yml configuration, as follows: by loading different yml, you can start server1 and server2 respectively constitute eureka cluster, responsible for service discovery and registration duties.
application.yml:
#注册中心应用名称
spring:
application:
name: eureka-server
#使用的配置文件名 `java -jar -Dspring.profiles.active=serverX demo.jar`启动serverX配置
profiles:
active: server1
application-server1.yml:
#注册中心运行的端口号
server:
port: 8001
#注册中心应用名称
#spring:
# application:
# name: eureka-server
#eureka.server.enableSelfPreservation:是否向注册中心注册自己
#通过eureka.client.registerWithEureka：false和fetchRegistry：false来表明自己是一个eureka server.
eureka:
# 自我保护机制
#server:
#enableSelfPreservation: false #关闭eureka的自我保护 小规模项目关闭比较好
#eviction-interval-timer-in-ms: 5000 #清理间隔时间，单位为毫秒（默认值60 * 1000）
#use-read-only-response-cache: false
instance:
hostname: server1
prefer-ip-address: false
# ip-address: 172.193.225.185
# instance-id: ${spring.cloud.client.ipAddress}:${server.port}
client:
fetch-registry: true
register-with-eureka: true
service-url:
defaultZone: http://server2:8002/eureka/
application-server2.yml:
#注册中心运行的端口号
server:
port: 8002
#注册中心应用名称
#spring:
# application:
# name: eureka-server
#eureka.server.enableSelfPreservation:是否向注册中心注册自己
#通过eureka.client.registerWithEureka：false和fetchRegistry：false来表明自己是一个eureka server.
eureka:
# 自我保护机制
#server:
#enableSelfPreservation: false #关闭eureka的自我保护 小规模项目关闭比较好
#eviction-interval-timer-in-ms: 3000 #清理间隔时间，单位为毫秒（默认值60 * 1000）
#use-read-only-response-cache: false
instance:
hostname: server2
prefer-ip-address: false
# ip-address: 172.193.225.185
# instance-id: ${spring.cloud.client.ipAddress}:${server.port}
client:
fetch-registry: true
register-with-eureka: true
service-url:
defaultZone: http://server1:8001/eureka/
cloud_zuul module
This module is the gateway for all micro services, here is zuul, now officially spring gradually abandoned zuul, instead of using its own gateway gateway component, because zuul io is blocked, but the configuration can be compared zuul configuration. Gateway component also needs to be registered in the eureka.
application.yml follows, ribbon and hystrix timeout require special configuration bit, otherwise the project started after the first great probability will report a timeout error hystrix timeout (the default time-out for a short time) gateway access through the service, ribbon responsible for load balancing, hystrix responsible for service fuse, the fuse so the configuration of service time should be greater than the total time load balancing, otherwise it would have been prompted to warn.
Services blown-out time is calculated as follows:
(1 + MaxAutoRetries + MaxAutoRetriesNextServer) * ReadTimeout, plus 1 is not counted because the first visit retries, MaxAutoRetries for the same instance of the maximum number of calls, the default is 1, MaxAutoRetriesNextServer to switch to other instances the maximum number, the default is 1, the fuse is greater than the timeout retry, retry otherwise would be meaningless here by calculating the timeout to 20,000, so hystrix timeout setting that is slightly larger than the 20,000 30,000 can.
#网关
spring:
application:
name: cloud-zuul
eureka:
client:
service-url:
defaultZone: http://server1:8001/eureka/,http://server2:8002/eureka/
instance:
prefer-ip-address: true
server:
port: 7001
zuul:
routes:
cloud-service1: #测试service1
path: /service1/**
serviceId: cloud-service1
cloud-service2: #测试service1
path: /service2/**
serviceId: cloud-service2
host:
connect-timeout-millis: 15000
socket-timeout-millis: 10000
ribbon:
ConnectTimeout: 5000
ReadTimeout: 5000
hystrix:
command:
default:
execution:
isolation:
thread:
timeoutInMilliseconds: 30000
cloud_config module
This module springcloud distribution center, can pull the profile from a remote repository git, while it does not need to register them eureka.
application.yml follows: rabbitmq configuration to achieve the main role of the service bus. Http sent to the user config: // localhost: 6001 / actuator / bus-refresh request, config configuration update message is sent to the rabbitmq, configure the service module micro-bus service will listen to this message, it will pull back from the remote take the configuration file and reload, so we modified the configuration file without restarting the project in a remote repository update configuration can be achieved.
server:
port: 6001
spring:
application:
name: cloud-config
cloud:
config:
server:
git:
uri: https://gitee.com/zrxjava/cloudModel_config.git
rabbitmq:
host: 127.0.0.1
username: guest
password: guest
#刷新总线的接口
management:
endpoints:
jmx:
exposure:
exclude: bus-refresh
cloud_service1 module
service1 is one of the micro-service module, but it also registered in eureka among the service1 using a feign to call service2, we know that micro-services can be invoked by a ribbon and feign, the difference is, ribbon using restTemplate way call, the ribbon package is Feign layer, using call interface in the form, and the default support load balancing, while also selectively turn fuse service, client code Feign follows:
package consumer.client;
import consumer.client.impl.Service2ClientImpl;
import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.stereotype.Component;
import org.springframework.web.bind.annotation.GetMapping;
@Component //仅仅是为了屏蔽idea误显示的注入错误
@FeignClient(value = "cloud-service2", fallback = Service2ClientImpl.class)
public interface Service2Client {
@GetMapping("/test/do")
public String test();
}
package consumer.client.impl;
import consumer.client.Service2Client;
import org.springframework.stereotype.Component;
//熔断器执行的方法
@Component
public class Service2ClientImpl implements Service2Client {
@Override
public String test() {
return "触发熔断器！";
}
}
service1 configuration file by config configuration management center, start service1 when loaded bootstrap.yml configuration profile from the pull gitee, config configuration of the center is to facilitate operation and maintenance, after springcloud-bus configuration without having to restart the project can loading a configuration file, an exercise in operation and maintenance of the gospel. bootstrap.yml reads as follows:
spring:
cloud:
config:
name: service1 #对应git服务器上的name #name-profile
profile: dev #对应git服务器上的profile
label: master #提交到master分支
uri: http://localhost:6001 #config的访问地址
gitee warehouse service-dev.yml reads as follows:
#注册中心应用名称
spring:
application:
name: cloud-service1
rabbitmq:
host: 127.0.0.1
username: guest
password: guest
eureka:
client:
service-url:
defaultZone: http://server1:8001/eureka/,http://server2:8002/eureka/
instance:
prefer-ip-address: true
server:
port: 9001
feign:
hystrix:
enabled: true
ribbon:
ConnectTimeout: 5000
ReadTimeout: 5000
hystrix:
command:
default:
execution:
isolation:
thread:
timeoutInMilliseconds: 30000
cloud_service2 module
service2 service1 with the same registered into the eureka while it is only for registered into the eureka in service1 call, in a real project which, each micro-services can call each other, but here I stole a lazy, no feign client calls, that is, it can also call service1.
application.yml as follows:
#注册中心应用名称
spring:
application:
name: cloud-service2
eureka:
client:
service-url:
defaultZone: http://server1:8001/eureka/,http://server2:8002/eureka/
instance:
prefer-ip-address: true
server:
port: 9002
test
First, we start eureka constitute two clusters, respectively, using server1 and server2 file to start the project (in respect of the other party does not start being given first start, and when the other party Booted error will automatically disappear, as both parties are registered with each other to form a highly available after the cluster), the boot is completed, visit http: // localhost: 8001 / to see server1 interface, as follows:
Similarly, server2 also be a normal visit, and there is no longer a screenshot.
Took over the startup configuration center of attention yml service1 need to get through the config remote, so you need to start the configuration center config, and then start service1 and service2 respectively, and finally start zuul. If you do not rabbitmq configuration, startup config and service1 will complain failure (can not connect prompt rabbitmq service), they can not start. After all the boot is completed, the registry has been found eureka respective service registration information, as shown:
As shown above, we successfully launched two service micro services and zuul service gateway. Here red font eureka interface is due to self-protection mechanism eureka trigger, not an error, when the number of received total renewal last minute service instance eureka received renewal / per minute desired <85% of the time , self-protection mechanism is triggered to tell you might have a problem node (such as network latency, service is not really hung up), but it is not going to eliminate it, will retain their registration information, return to normal until the node can still continue work, which makes the entire service more highly available.
Finally, we visit service1 through zuul gateway address of the service (service1 calls by feign service2), visit http: // localhost: 7001 / service1 / test / do ( if not start config and service1, visit http: // localhost: 7001 / service2 / test / do), as follows:
As a result, the entire process is over, springcloud core components will explain finished.
Micro Services reverie
It is worth mentioning that, in a real micro-services project, the number of services far more than that, the code generator only help you build a basic architectural model. So if manually deploy management approach will become extremely difficult, but later with the development of containerization technology, each service is generated by dockerfile the mirror run dokcer container gradually become a mainstream mode of deployment operation and maintenance, and by more easily maven plugin can be a key building dockerfile file generated image and upload it to docker, PW, we can upload our own micro-serving image files and run them very easily through docker PW, continuous integration by jenkins, while giving micro-service publishing Finally, in order to unify management docker container, k8s than docker swarm become the darling of the new generation of container applications, the era of rapid development, iterative technology is also fast!
Recently micro-channel chat with friends, learned that Service Mesh technology is quietly rising, manufacturers have landed applications, simple to understand, service mesh to each micro-services made further decoupling, the communication related operations (load balancing, circuit breakers, etc.) pulled out, generate a proxy service for each micro-services, and micro-services did really only need to worry about business. Previous micro service is a unicycle, has now become a two-wheeled vehicle, so it was also called "sidecar mode", the service each agent connected by lines together to form a complex grid, service mesh also on the resulting, later evolved into a centralized control panel to manage one grid, representative works: Istio.
But the same, due to take over the service mesh network flow stability of the system will depend on the service mesh, while compared to the previous instance of a large number of service mesh additionally introduced for operation and maintenance and management is also a huge challenge.
service mesh is the future development trend of micro-services, history is always surprisingly similar, very beginning, end-to-people communication in order to solve the problem, tcp agreement turned out, multi-machine communication from becoming simple and reliable. Now we come to the micro-service era, in order to shield the complexity of distributed communication systems, service mesh emerged. This allows us to return to business, focused real value!
Code generator: Click to download
