微服务开发,微服务服务注册发现与如何实现容器部署

微服务开发，微服务服务注册发现与如何实现容器部署？

微服务技术现在正炙手可热，因为使用微服务让系统的安全性，稳定性得以保证！

什么是微服务？区别于原来的单一系统，微服务是通过服务拆分，分布在不同的服务器上，并以一定的通信方式传递数据，实现各服务之间的解耦合的一套分布式架构！

既然分布在不同的服务器上，服务间通信的问题就是不可避免的问题，引进中间组件来维护服务是必不可缺的选择！

服务注册与发现有多种方式，比如dubbo使用zk，springcloud使用eureka等！下面就以eureka为例:

eureka分为server和client，将client放在业务服务代码中定时向eureka server注册服务，在server端统一进行维护一份服务列表，等到服务消费方调用服务的时候，先经过服务注册中心，找到相应服务实现调用！

springcloud项目中具体实现如下:1，搭建服务注册中心服务端:加入eureka server依赖，在启动类中加入@EnableEurekaServer注解，配置文件加入端口，是否注册自己等，启动服务类，访问localhost:8080/可以看到服务列表信息！

2，代码端搭建注册中心客户端:加入eureka client 依赖，启动类中加入@EnableClientSetver注解，配置文件加入相应的注册信息，启动服务，在服务端的服务列表中查看是否注册成功！

不仅如此，注册中心的服务端还可以使用多台机器进行负载均衡，实现多个服务端之间的相互注册，防止单点宕机引起服务停止！

如何使用docker容器？

1，安装docker！

2，在springcloud项目中根目录创建dockerfile文件，指定jdk版本，启动脚本等！

3，编译镜像:docker build，注意指定路径！

4，运行镜像:docker run！

5，使用ip地址和端口验证服务部署成功！

JAVA方面的更多技术分享，敬请关注。。。

java开发在现在这种微服务架构体系中？

当然能使用各种设计模式，Spring框架中有很多设计模式的体现，只要能在微服务体系中最终满足BASE理论，不还是照样在使用？

先说说设计模式

设计模式不是一种框架或中间件技术，而是对学习工作中代码进行高层次抽象的总结。设计模式不限于某种编程语言，JavaScript有设计模式，Java也有设计模式，只是表象不同而己。

根据用途可将设计模式分为三类：结构型模式、行为型模式和创建型模式。经典设计模式有23种，每一个设计模式也有多种实现，例如单例模式（懒汉、饿汉、静态内部类和DCL等），还是题主说到的工厂模式（简单工厂模式、工厂方法模式等）等。

分布式与微服务架构

随着开发的项目越来越繁杂，开发效率和高并发情况下要求高可用，项目模块化与容错机制就显得很有必要，分布式孕育而生。将每个开发模块部署到独立的云服务主机上，就好像多个人在一起做不同分工的事，但是整个过程是相互协作完成，这和集群的理念相反。而微服务算是一种架构，也属于分布式范畴，例如SpringCloud就是微服务架构的一种体现。

Spring中常用的设计模式

学习Java语言，Spring是必经之路，SringMVC和SringBoot等都是Sring框架的衍生品。现在使用SringBoot结合SpringCloud实现微服务与分布式不是什么新鲜技术，在初创或者开发成本预算不多的公司已经是首先技术架构，上手容易，生态支持友好。

Spring框架中有很多设计模式体现。例如简单工厂模式之BeanFactory，根据传入一个唯一的标识来获得Bean对象。再比如Spring下默认的Bean注解均为单例模式，将提供一个访问它的全局访问点，你可以通过设置singleton=“true|false”或者 scope="?"来指定作用范围，例如RabbitMq需要ACK回调机制确保消息发送到交换机的话，rabbitmqTemplate就不能为单例模式，需要设置scope=SCOPE_PROTOTYPE，并通过构造方法注入而非Autowrite注解。还有在Aop中，使用Advice来增强被代理类的功能而使用到的代理模式等等。这些都没有因为微服务体系的出现而被舍弃掉。

从以上三个方面阐述就会发现，微服务出现并不会导致现有一些技术或理论直接被弃用，而是通过新的理论或思想将这些精髓沿用，尽可能去靠近CAP原则。