ຮຽນ​ຮູ້​ວິ​ທີ​ການ​ນໍາ​ໃຊ້ microservices​. ສ່ວນທີ 1. Spring Boot ແລະ Docker

Hey Habr.

ໃນບົດຄວາມນີ້, ຂ້ອຍຕ້ອງການເວົ້າກ່ຽວກັບປະສົບການຂອງຂ້ອຍໃນການສ້າງສະພາບແວດລ້ອມການຮຽນຮູ້ສໍາລັບການທົດລອງກັບ microservices. ເມື່ອຮຽນຮູ້ທຸກເຄື່ອງມືໃຫມ່, ຂ້າພະເຈົ້າສະເຫມີຢາກພະຍາຍາມມັນບໍ່ພຽງແຕ່ຢູ່ໃນເຄື່ອງທ້ອງຖິ່ນຂອງຂ້ອຍເທົ່ານັ້ນ, ແຕ່ຍັງຢູ່ໃນສະພາບຕົວຈິງຫຼາຍຂຶ້ນ. ດັ່ງນັ້ນ, ຂ້າພະເຈົ້າໄດ້ຕັດສິນໃຈສ້າງຄໍາຮ້ອງສະຫມັກການບໍລິການຈຸນລະພາກທີ່ງ່າຍດາຍ, ເຊິ່ງຕໍ່ມາສາມາດ "ຫ້ອຍ" ກັບທຸກປະເພດຂອງເຕັກໂນໂລຢີທີ່ຫນ້າສົນໃຈ. ຄວາມຕ້ອງການຕົ້ນຕໍສໍາລັບໂຄງການແມ່ນຄວາມໃກ້ຊິດທີ່ເປັນປະໂຫຍດສູງສຸດກັບລະບົບທີ່ແທ້ຈິງ.

ໃນເບື້ອງຕົ້ນ, ຂ້າພະເຈົ້າໄດ້ແບ່ງການສ້າງໂຄງການອອກເປັນຫຼາຍຂັ້ນຕອນ:

1. ສ້າງສອງບໍລິການ - 'backend' ແລະ 'gateway', pack ພວກມັນເຂົ້າໄປໃນຮູບ docker ແລະ configure ໃຫ້ເຂົາເຈົ້າເຮັດວຽກຮ່ວມກັນ

   ຄໍາສໍາຄັນ: Java 11, Spring Boot, Docker, ການເພີ່ມປະສິດທິພາບຮູບພາບ

2. ການພັດທະນາລະບົບການຕັ້ງຄ່າ ແລະການນຳໃຊ້ Kubernetes ໃນ Google Kubernetes Engine

   ຄໍາສໍາຄັນ: Kubernetes, GKE, ການຄຸ້ມຄອງຊັບພະຍາກອນ, autoscaling, ຄວາມລັບ

3. ສ້າງຕາຕະລາງໂດຍໃຊ້ Helm 3 ສໍາລັບການຈັດການກຸ່ມທີ່ມີປະສິດທິພາບຫຼາຍຂຶ້ນ

   ຄໍາສໍາຄັນ: Helm 3, ການປະຕິບັດຕາຕະລາງ

4. ການຕັ້ງຄ່າ Jenkins ແລະທໍ່ສົ່ງລະຫັດອັດຕະໂນມັດໄປຫາກຸ່ມ

   ຄໍາສໍາຄັນ: ການຕັ້ງຄ່າ Jenkins, plugins, repository configs ແຍກຕ່າງຫາກ

ຂ້ອຍວາງແຜນທີ່ຈະອຸທິດບົດຄວາມແຍກຕ່າງຫາກໃນແຕ່ລະຂັ້ນຕອນ.

ຈຸດສຸມຂອງບົດຄວາມຊຸດນີ້ແມ່ນບໍ່ແມ່ນວິທີການຂຽນ microservices, ແຕ່ວິທີການເຮັດໃຫ້ພວກມັນເຮັດວຽກຢູ່ໃນລະບົບດຽວ. ໃນຂະນະທີ່ສິ່ງທັງຫມົດເຫຼົ່ານີ້ມັກຈະຢູ່ນອກຄວາມຮັບຜິດຊອບຂອງນັກພັດທະນາ, ຂ້າພະເຈົ້າຄິດວ່າມັນຍັງເປັນປະໂຫຍດທີ່ຈະມີຄວາມຄຸ້ນເຄີຍກັບພວກເຂົາຢ່າງຫນ້ອຍ 20% (ເຊິ່ງຮູ້ວ່າກວມເອົາ 80% ຂອງຜົນໄດ້ຮັບ). ບາງຫົວຂໍ້ທີ່ສໍາຄັນເຊັ່ນ: ຄວາມປອດໄພ, ຈະຖືກປະໄວ້ຈາກໂຄງການນີ້, ນັບຕັ້ງແຕ່ຜູ້ຂຽນເຂົ້າໃຈພຽງເລັກນ້ອຍກ່ຽວກັບເລື່ອງນີ້; ລະບົບກໍາລັງຖືກສ້າງຂື້ນສະເພາະສໍາລັບການນໍາໃຊ້ສ່ວນບຸກຄົນ. ຂ້າ​ພະ​ເຈົ້າ​ຍິນ​ດີ​ຕ້ອນ​ຮັບ​ຄວາມ​ຄິດ​ເຫັນ​ແລະ​ການ​ວິ​ຈານ​ໃນ​ການ​ກໍ່​ສ້າງ.

ການສ້າງ microservices

ການບໍລິການໄດ້ຖືກຂຽນໄວ້ໃນ Java 11 ໂດຍໃຊ້ Spring Boot. ການສື່ສານລະຫວ່າງການບໍລິການຖືກຈັດຕັ້ງໂດຍໃຊ້ REST. ໂຄງການດັ່ງກ່າວຈະປະກອບມີຈໍານວນການທົດສອບຕໍາ່ສຸດທີ່ (ດັ່ງນັ້ນຕໍ່ມາຈະມີບາງສິ່ງບາງຢ່າງທີ່ຈະທົດສອບໃນ Jenkins). ລະຫັດແຫຼ່ງສໍາລັບການບໍລິການແມ່ນມີຢູ່ໃນ GitHub: ດ້ານຫຼັງ и ປະຕູ.

ເພື່ອໃຫ້ສາມາດກວດສອບສະຖານະຂອງແຕ່ລະບໍລິການ, Spring Actuator ໄດ້ຖືກເພີ່ມເຂົ້າໃນການເພິ່ງພາອາໄສຂອງພວກເຂົາ. ມັນຈະສ້າງຈຸດສິ້ນສຸດ / ຕົວກະຕຸ້ນ / ສຸຂະພາບແລະຈະກັບຄືນສະຖານະພາບຂອງ 200 ຖ້າການບໍລິການພ້ອມທີ່ຈະຍອມຮັບການຈະລາຈອນ, ຫຼື 504 ໃນກໍລະນີທີ່ມີບັນຫາ. ໃນກໍລະນີນີ້, ນີ້ແມ່ນການກວດສອບທີ່ສົມມຸດຕິຖານ, ເພາະວ່າການບໍລິການແມ່ນງ່າຍດາຍຫຼາຍ, ແລະພາຍໃຕ້ສະຖານະການບັງຄັບບາງຊະນິດ, ພວກມັນມັກຈະບໍ່ສາມາດໃຊ້ໄດ້ຢ່າງສົມບູນກ່ວາການດໍາເນີນການບາງສ່ວນ. ແຕ່ໃນລະບົບທີ່ແທ້ຈິງ, Actuator ສາມາດຊ່ວຍວິນິດໄສບັນຫາກ່ອນທີ່ຜູ້ໃຊ້ຈະເລີ່ມຕີມັນ. ຕົວຢ່າງ, ຖ້າບັນຫາເກີດຂຶ້ນກັບການເຂົ້າເຖິງຖານຂໍ້ມູນ, ພວກເຮົາຈະສາມາດຕອບສະຫນອງອັດຕະໂນມັດຕໍ່ກັບການນີ້ໂດຍການຢຸດການຮ້ອງຂໍການປະມວນຜົນດ້ວຍຕົວຢ່າງທີ່ແຕກຫັກຂອງການບໍລິການ.

ບໍລິການດ້ານຫຼັງ

ບໍລິການ backend ພຽງແຕ່ຈະນັບແລະສົ່ງຄືນຈໍານວນຄໍາຮ້ອງຂໍທີ່ຍອມຮັບ.

ລະຫັດຄວບຄຸມ:

@RestController
public class RequestsCounterController {

    private final AtomicLong counter = new AtomicLong();

    @GetMapping("/requests")
    public Long getRequestsCount() {
        return counter.incrementAndGet();
    }
}

ການ​ທົດ​ສອບ​ການ​ຄວບ​ຄຸມ​:

@WebMvcTest(RequestsCounterController.class)
public class RequestsCounterControllerTests {

    @Autowired
    private MockMvc mockMvc;

    @Test
    public void firstRequest_one() throws Exception {
        mockMvc.perform(get("/requests"))
            .andExpect(status().isOk())
            .andExpect(MockMvcResultMatchers.content().string("1"));
    }
}

ບໍລິການຜ່ານປະຕູ

gateway ຈະສົ່ງຕໍ່ຄໍາຮ້ອງຂໍໄປຍັງບໍລິການ backend, ເສີມມັນດ້ວຍຂໍ້ມູນດັ່ງຕໍ່ໄປນີ້:

• ລະຫັດປະຕູ. ມັນເປັນສິ່ງຈໍາເປັນເພື່ອໃຫ້ຕົວຢ່າງຫນຶ່ງຂອງປະຕູສາມາດໄດ້ຮັບການຈໍາແນກຈາກອື່ນໂດຍການຕອບສະຫນອງຂອງເຄື່ອງແມ່ຂ່າຍ
• "ຄວາມລັບ" ທີ່ແນ່ນອນທີ່ຈະມີບົດບາດຂອງລະຫັດຜ່ານທີ່ສໍາຄັນຫຼາຍ (ຫມາຍເລກລະຫັດສໍາລັບການເຂົ້າລະຫັດຄຸກກີທີ່ສໍາຄັນ)

ການຕັ້ງຄ່າໃນ application.properties:

backend.url=http://localhost:8081
instance.id=${random.int}
secret="default-secret"

ອະແດັບເຕີສໍາລັບການສື່ສານກັບ backend:

@Service
public class BackendAdapter {

    private static final String REQUESTS_ENDPOINT = "/requests";

    private final RestTemplate restTemplate;

    @Value("${backend.url}")
    private String backendUrl;

    public BackendAdapter(RestTemplateBuilder builder) {
        restTemplate = builder.build();
    }

    public String getRequests() {
        ResponseEntity<String> response = restTemplate.getForEntity(
backendUrl + REQUESTS_ENDPOINT, String.class);
        return response.getBody();
    }
}

ຕົວຄວບຄຸມ:

@RestController
@RequiredArgsConstructor
public class EndpointController {

    private final BackendAdapter backendAdapter;

    @Value("${instance.id}")
    private int instanceId;

    @Value("${secret}")
    private String secret;

    @GetMapping("/")
    public String getRequestsCount() {
        return String.format("Number of requests %s (gateway %d, secret %s)", backendAdapter.getRequests(), instanceId, secret);
    }
}

ເປີດຕົວ:

ມາເປີດສາກຫຼັງ:

./mvnw package -DskipTests
java -Dserver.port=8081 -jar target/microservices-backend-1.0.0.jar

ໃຫ້ເລີ່ມຕົ້ນປະຕູ:

./mvnw package -DskipTests
java -jar target/microservices-gateway-1.0.0.jar

ພວກເຮົາກວດເບິ່ງ:

$ curl http://localhost:8080/
Number of requests 1 (gateway 38560358, secret "default-secret")

ທຸກສິ່ງທຸກຢ່າງແມ່ນເຮັດວຽກ. ຜູ້ອ່ານທີ່ເອົາໃຈໃສ່ຈະສັງເກດວ່າບໍ່ມີຫຍັງກີດຂວາງພວກເຮົາຈາກການເຂົ້າເຖິງ backend ໂດຍກົງ, ຂ້າມປະຕູ (http://localhost:8081/requests). ເພື່ອແກ້ໄຂບັນຫານີ້, ການບໍລິການຕ້ອງຖືກລວມເຂົ້າກັນເປັນເຄືອຂ່າຍດຽວ, ແລະພຽງແຕ່ປະຕູທີ່ຄວນຈະ "ຕິດ" ພາຍນອກ.
ນອກຈາກນີ້, ທັງສອງບໍລິການແບ່ງປັນລະບົບໄຟລ໌ດຽວກັນ, ສ້າງກະທູ້, ແລະຈຸດຫນຶ່ງສາມາດເລີ່ມຕົ້ນແຊກແຊງເຊິ່ງກັນແລະກັນ. ມັນຈະເປັນການດີທີ່ຈະແຍກ microservices ຂອງພວກເຮົາ. ນີ້ສາມາດບັນລຸໄດ້ໂດຍການແຈກຢາຍຄໍາຮ້ອງສະຫມັກໃນທົ່ວເຄື່ອງທີ່ແຕກຕ່າງກັນ (ເງິນຫຼາຍ, ມີຄວາມຫຍຸ້ງຍາກ), ການນໍາໃຊ້ເຄື່ອງຈັກ virtual (ຊັບພະຍາກອນຫຼາຍ, ການເລີ່ມຕົ້ນຍາວ) ຫຼືການນໍາໃຊ້ containerization. ດັ່ງທີ່ຄາດໄວ້, ພວກເຮົາເລືອກທາງເລືອກທີສາມແລະ Docker ເປັນເຄື່ອງມືສໍາລັບການບັນຈຸ.

Docker

ໃນສັ້ນ, Docker ສ້າງບັນຈຸທີ່ໂດດດ່ຽວ, ຫນຶ່ງຕໍ່ຄໍາຮ້ອງສະຫມັກ. ເພື່ອໃຊ້ Docker, ທ່ານຈໍາເປັນຕ້ອງຂຽນ Dockerfile - ຄໍາແນະນໍາສໍາລັບການກໍ່ສ້າງແລະແລ່ນແອັບພລິເຄຊັນ. ຕໍ່​ໄປ​, ທ່ານ​ສາ​ມາດ​ສ້າງ​ຮູບ​ພາບ​, ອັບ​ມັນ​ກັບ​ການ​ຈົດ​ທະ​ບຽນ​ຮູບ​ພາບ (ບໍ່​. Dockerhub) ແລະນຳໃຊ້ບໍລິການຈຸນລະພາກຂອງທ່ານໃນສະພາບແວດລ້ອມ dockerized ໃນຄໍາສັ່ງດຽວ.

dockerfile

ຫນຶ່ງໃນລັກສະນະທີ່ສໍາຄັນທີ່ສຸດຂອງຮູບພາບແມ່ນຂະຫນາດຂອງມັນ. ຮູບພາບຂະໜາດນ້ອຍຈະດາວໂຫຼດໄວຂຶ້ນຈາກບ່ອນເກັບມ້ຽນທາງໄກ, ໃຊ້ພື້ນທີ່ໜ້ອຍລົງ, ແລະການບໍລິການຂອງທ່ານຈະເລີ່ມໄວຂຶ້ນ. ຮູບພາບໃດກໍ່ຖືກສ້າງຂຶ້ນບົນພື້ນຖານຂອງຮູບພາບພື້ນຖານ, ແລະແນະນໍາໃຫ້ເລືອກທາງເລືອກທີ່ຫນ້ອຍທີ່ສຸດ. ທາງ​ເລືອກ​ທີ່​ດີ​ແມ່ນ Alpine, ການ​ແຜ່​ກະ​ຈາຍ Linux ຢ່າງ​ເຕັມ​ທີ່​ທີ່​ມີ​ຢ່າງ​ຫນ້ອຍ​ຂອງ​ການ​ຫຸ້ມ​ຫໍ່.

ທໍາອິດ, ໃຫ້ພະຍາຍາມຂຽນ Dockerfile "head-on" (ຂ້າພະເຈົ້າຈະເວົ້າທັນທີວ່ານີ້ແມ່ນວິທີທີ່ບໍ່ດີ, ຢ່າເຮັດ):

FROM adoptopenjdk/openjdk11:jdk-11.0.5_10-alpine
ADD . /src
WORKDIR /src
RUN ./mvnw package -DskipTests
EXPOSE 8080
ENTRYPOINT ["java","-jar","target/microservices-gateway-1.0.0.jar"]

ໃນທີ່ນີ້ພວກເຮົາກໍາລັງໃຊ້ຮູບພາບພື້ນຖານຂອງ Alpine ກັບ JDK ທີ່ຕິດຕັ້ງແລ້ວເພື່ອສ້າງໂຄງການຂອງພວກເຮົາ. ການນໍາໃຊ້ຄໍາສັ່ງ ADD, ພວກເຮົາເພີ່ມໄດເລກະທໍລີ src ໃນປັດຈຸບັນໃສ່ຮູບພາບ, ຫມາຍວ່າມັນເຮັດວຽກ (WORKDIR) ແລະເລີ່ມຕົ້ນການກໍ່ສ້າງ. ຄໍາສັ່ງ EXPOSE 8080 ສັນຍານກັບ docker ວ່າແອັບພລິເຄຊັນໃນ container ຈະໃຊ້ພອດ 8080 ຂອງມັນ (ອັນນີ້ຈະບໍ່ເຮັດໃຫ້ແອັບພລິເຄຊັນສາມາດເຂົ້າເຖິງໄດ້ຈາກພາຍນອກ, ແຕ່ຈະອະນຸຍາດໃຫ້ແອັບພລິເຄຊັນເຂົ້າເຖິງໄດ້, ຕົວຢ່າງ, ຈາກ container ອື່ນໃນເຄືອຂ່າຍ docker ດຽວກັນ. ).

ເພື່ອຫຸ້ມຫໍ່ການບໍລິການເຂົ້າໄປໃນຮູບພາບ, ທ່ານຈໍາເປັນຕ້ອງດໍາເນີນການຄໍາສັ່ງຈາກຮາກຂອງແຕ່ລະໂຄງການ:

docker image build . -t msvc-backend:1.0.0

ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ຮັບຮູບພາບທີ່ມີຂະຫນາດ 456 MB (ເຊິ່ງຮູບພາບ JDK 340 ພື້ນຖານໄດ້ MB). ແລະທັງຫມົດເຖິງວ່າຈະມີຄວາມຈິງທີ່ວ່າຫ້ອງຮຽນໃນໂຄງການຂອງພວກເຮົາສາມາດຖືກນັບຢູ່ໃນນິ້ວມືຫນຶ່ງ. ເພື່ອຫຼຸດຂະໜາດຂອງຮູບຂອງພວກເຮົາ:

• ພວກເຮົາໃຊ້ການປະກອບຫຼາຍຂັ້ນຕອນ. ໃນຂັ້ນຕອນທໍາອິດພວກເຮົາຈະປະກອບໂຄງການ, ໃນທີສອງພວກເຮົາຈະຕິດຕັ້ງ JRE, ແລະໃນຂັ້ນຕອນທີສາມພວກເຮົາຈະຄັດລອກທັງຫມົດນີ້ເຂົ້າໄປໃນຮູບ Alpine ທີ່ສະອາດໃຫມ່. ໃນຈໍານວນທັງຫມົດ, ຮູບພາບສຸດທ້າຍຈະມີພຽງແຕ່ອົງປະກອບທີ່ຈໍາເປັນ.
• ໃຫ້ໃຊ້ java modularization. ເລີ່ມຕົ້ນດ້ວຍ Java 9, ທ່ານສາມາດນໍາໃຊ້ເຄື່ອງມື jlink ເພື່ອສ້າງ JRE ຈາກພຽງແຕ່ໂມດູນທີ່ທ່ານຕ້ອງການ

ສໍາລັບຜູ້ທີ່ຢາກຮູ້ຢາກເຫັນ, ນີ້ແມ່ນບົດຄວາມທີ່ດີກ່ຽວກັບວິທີການຫຼຸດຜ່ອນຂະຫນາດຮູບພາບ https://habr.com/ru/company/ruvds/blog/485650/.

Dockerfile ສຸດທ້າຍ:

FROM adoptopenjdk/openjdk11:jdk-11.0.5_10-alpine as builder
ADD . /src
WORKDIR /src
RUN ./mvnw package -DskipTests

FROM alpine:3.10.3 as packager
RUN apk --no-cache add openjdk11-jdk openjdk11-jmods
ENV JAVA_MINIMAL="/opt/java-minimal"
RUN /usr/lib/jvm/java-11-openjdk/bin/jlink 
    --verbose 
    --add-modules 
        java.base,java.sql,java.naming,java.desktop,java.management,java.security.jgss,java.instrument 
    --compress 2 --strip-debug --no-header-files --no-man-pages 
    --release-info="add:IMPLEMENTOR=radistao:IMPLEMENTOR_VERSION=radistao_JRE" 
    --output "$JAVA_MINIMAL"

FROM alpine:3.10.3
LABEL maintainer="Anton Shelenkov [email protected]"
ENV JAVA_HOME=/opt/java-minimal
ENV PATH="$PATH:$JAVA_HOME/bin"
COPY --from=packager "$JAVA_HOME" "$JAVA_HOME"
COPY --from=builder /src/target/microservices-backend-*.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java","-jar","/app.jar"]

ພວກເຮົາສ້າງຮູບຄືນໃໝ່, ແລະໃນທີ່ສຸດມັນກໍບາງລົງ 6 ເທົ່າ, ເທົ່າກັບ 77 MB. ບໍ່ດີ. ຫຼັງ​ຈາກ​ນັ້ນ​, ຮູບ​ພາບ​ສໍາ​ເລັດ​ຮູບ​ສາ​ມາດ​ໄດ້​ຮັບ​ການ​ອັບ​ໂຫຼດ​ກັບ​ການ​ຈົດ​ທະ​ບຽນ​ຮູບ​ພາບ​ເພື່ອ​ໃຫ້​ຮູບ​ພາບ​ຂອງ​ທ່ານ​ມີ​ສໍາ​ລັບ​ການ​ດາວ​ໂຫຼດ​ຈາກ​ອິນ​ເຕີ​ເນັດ​.

ແລ່ນບໍລິການຮ່ວມກັນໃນ Docker

ເພື່ອເລີ່ມຕົ້ນດ້ວຍ, ການບໍລິການຂອງພວກເຮົາຕ້ອງຢູ່ໃນເຄືອຂ່າຍດຽວກັນ. ມີຫຼາຍປະເພດຂອງເຄືອຂ່າຍໃນ Docker, ແລະພວກເຮົາໃຊ້ primitive ທີ່ສຸດຂອງພວກເຂົາ - ຂົວ, ເຊິ່ງຊ່ວຍໃຫ້ທ່ານສາມາດເຄືອຂ່າຍບັນຈຸທີ່ເຮັດວຽກຢູ່ໃນໂຮດດຽວກັນ. ມາສ້າງເຄືອຂ່າຍດ້ວຍຄຳສັ່ງຕໍ່ໄປນີ້:

docker network create msvc-network

ຕໍ່ໄປ, ໃຫ້ເປີດຕົວບັນຈຸ backend ທີ່ມີຊື່ວ່າ 'backend' ກັບ microservices-backend: 1.0.0:

docker run -dit --name backend --network msvc-net microservices-backend:1.0.0

ມັນເປັນມູນຄ່າທີ່ສັງເກດວ່າເຄືອຂ່າຍຂົວສະຫນອງການບໍລິການຄົ້ນພົບອອກຈາກກ່ອງສໍາລັບຕູ້ຄອນເທນເນີໂດຍຊື່ຂອງພວກເຂົາ. ນັ້ນແມ່ນ, ການບໍລິການ backend ຈະມີຢູ່ໃນເຄືອຂ່າຍ Docker ຢູ່ http://backend:8080.

ໃຫ້ເລີ່ມຕົ້ນປະຕູ:

docker run -dit -p 80:8080 --env secret=my-real-secret --env BACKEND_URL=http://backend:8080/ --name gateway --network msvc-net microservices-gateway:1.0.0

ໃນຄໍາສັ່ງນີ້ພວກເຮົາຊີ້ໃຫ້ເຫັນວ່າພວກເຮົາກໍາລັງສົ່ງຕໍ່ພອດ 80 ຂອງໂຮດຂອງພວກເຮົາໄປຫາພອດ 8080 ຂອງຕູ້ຄອນເທນເນີ. ພວກເຮົາໃຊ້ຕົວເລືອກ env ເພື່ອກໍານົດຕົວແປສະພາບແວດລ້ອມທີ່ຈະຖືກອ່ານໂດຍອັດຕະໂນມັດໃນພາກຮຽນ spring ແລະ override ຄຸນສົມບັດຈາກ application.properties.

ຫຼັງຈາກການເປີດຕົວ, ໂທຫາ http://localhost/ ແລະໃຫ້ແນ່ໃຈວ່າທຸກສິ່ງທຸກຢ່າງເຮັດວຽກ, ເຊັ່ນດຽວກັນກັບກໍລະນີທີ່ຜ່ານມາ.

ສະຫລຸບ

ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ສ້າງສອງ microservices ງ່າຍດາຍ, ຫຸ້ມຫໍ່ພວກມັນຢູ່ໃນ docker containers ແລະເປີດຕົວມັນຮ່ວມກັນໃນເຄື່ອງດຽວກັນ. ຢ່າງໃດກໍຕາມ, ລະບົບຜົນໄດ້ຮັບ, ມີຂໍ້ເສຍປຽບຈໍານວນຫນຶ່ງ:

• ຄວາມທົນທານຕໍ່ຄວາມຜິດພາດທີ່ບໍ່ດີ - ທຸກສິ່ງທຸກຢ່າງເຮັດວຽກຢູ່ໃນເຄື່ອງແມ່ຂ່າຍດຽວສໍາລັບພວກເຮົາ
• ຄວາມສາມາດໃນການຂະຫຍາຍໄດ້ບໍ່ດີ - ເມື່ອການໂຫຼດເພີ່ມຂຶ້ນ, ມັນຈະເປັນການດີທີ່ຈະນໍາໃຊ້ຕົວຢ່າງການບໍລິການເພີ່ມເຕີມໂດຍອັດຕະໂນມັດແລະດຸ່ນດ່ຽງການໂຫຼດລະຫວ່າງພວກມັນ.
• ການເປີດຕົວຄວາມສັບສົນ - ພວກເຮົາຕ້ອງການໃສ່ຢ່າງຫນ້ອຍ 3 ຄໍາສັ່ງ, ມີຕົວກໍານົດການທີ່ແນ່ນອນ (ນີ້ແມ່ນສໍາລັບ 2 ບໍລິການເທົ່ານັ້ນ)

ເພື່ອແກ້ໄຂບັນຫາຂ້າງເທິງ, ມີວິທີແກ້ໄຂຈໍານວນຫນຶ່ງເຊັ່ນ Docker Swarm, Nomad, Kubernetes ຫຼື OpenShift. ຖ້າລະບົບທັງຫມົດຖືກຂຽນໃນ Java, ທ່ານສາມາດເບິ່ງໄປຫາ Spring Cloud (ບົດ​ຄວາມ​ທີ່​ດີ​).

В ສ່ວນຕໍ່ໄປ ຂ້ອຍຈະບອກເຈົ້າກ່ຽວກັບວິທີທີ່ຂ້ອຍຕັ້ງ Kubernetes ແລະໃຊ້ໂຄງການກັບ Google Kubernetes Engine.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com