关于微服务架构（中台架构、领域驱动设计、组件设计原则），你有什么样的思考和认识？
关于微服务架构
微服务其实早就存在了大家的工作实践中，只是没有一个统一的理论来描述这个内容。
因为通常一个产品，不可能只有一个单体应用服务。只要有多个服务，就会出现微服务所需要解决的问题。
虽然，目前，可能大家工作中，并没有明确的说要使用微服务的概念，但是很自然的，都会按照业务功能来划分服务，每个人负责一个或多个服务的开发，服务之间通过http等方式相互调用。
问题是，怎么知道我所需要的服务ip端口？
通常，可能使用配置文件的方式，或者 调用域名的方式。也有自己实现的服务注册的功能，各服务连接到注册中心，上报自己的信息，定时心跳，注册中心把此服务写数据库，其他服务可以查询某种类型的所有服务的ip端口，然后定时刷新，在需要时调用对方服务。
这其中也也会涉及服务注册中心单点、服务断开、服务新增、服务删除等各种情况带来的问题。
服务之间如何通信? 可能使用http调用，可能使用私有协议的tcp/udp通信，可能轮询调用一种类型的多个ip地址。怎么信任调用方的服务？被调用方怎么负载均衡，调用出问题了怎么办？
配置文件怎么更新？可能一台服务一台服务更改
日志怎么查看分析？可能一台服务一台服务登上去查看
调用失败了，调用链怎么分析？可能还是一台服务一台服务登上去查看
怎么知道所有服务的当前状态？
这实际上，就是微服务。其实也都是在解决这些问题，只不过可能解决方式没有那么好而已。
所以，微服务简单而言，就是在解决怎么管理系统中的各个服务，以及服务间怎么高效通信的问题
比如dubbo，使用服务注册中心来进行服务的发现治理，使用rpc来进行服务间的通信
比如spring cloud，集成了各种类似功能的组件，诸如 Consul、Eureka 用于服务发现治理，Config、zookeeper用于服务治理和配置管理等等，可能更多的使用HTTP来进行通信
总之，微服务需要 管理 、监控 系统中的各服务，提供服务之间高效安全的调用方式，当然还包括网关、日志、调用链、负载均衡、断路器等等相关内容。
微服务实质上是在提供系统运行的一个基础设施，在基础设施之上，只需要开发业务代码，整个系统就可以正确运行起来。而基础设施的建造并不容易，就像装修相比较建造楼房，就容易的些。如果不能提供这些基础设施，微服务并不能很好的用起来。
网友评论