微服务是系统架构上的设计风格, 是将原本独立的系统拆分成多个小型服务, 这些小型服务在各自的进程中运行, 服务之间通过基于HTTP或RestFul API进行通信协作. 被拆分的每一个小型服务都围绕着系统中的某一项或一些耦合度较高的业务功能进行构建, 并且每个服务都维护着自身的数据存储, 业务开发, 自动化测试案例以及独立部署机制.
微服务架构的九大特性:
- 服务组件化
- 按业务组织团队, 对微服务团队的拆分按照业务线的方式进行拆分
- 做”产品”的态度, 以做产品的态度对待每一个微服务
智能端点与哑通道
这玩意你要先理解智能端点和哑管道的反面是什么？就是SOA概念中专注服务治理的企业服务总线（简称ESB），ESB实质上就是一个管道，也就是应用A要访问服务B，A要先发数据给ESB，然后ESB调用B，B产生的数据返给ESB，然后ESB再返给A，这样ESB不仅仅提供了路由的功能，而且把自己做成了一个大型企业系统的中心，基于此，又发展附加了原本不属于管道的功能，比如服务B提供的是socket服务，但是应用A是使用http调用，这时ESB发展出了转换报文的功能，甚至是服务B提供的是a,b,c三个数据，而应用A需要的是a，b，c拼接起来命名为d的数据，这也放在ESB中实现。这样就使得ESB实际上又承载了业务逻辑，使得原本复杂的系统通过服务治理把瓶颈和复杂度统统压到ESB一个中心点上去了，这跟微服务去中心化的思想截然相反。所以ESB这一危险度（ESB完蛋，全部系统都受影响，另外要上系统，通常先要给ESB组看一下，ESB需要一个额外的有执行力的团队去支撑）催生了微服务体系的智能端点和哑管道，相对ESB而言，微服务体系的管道只提供路由或者负载均衡之类的，不承载业务逻辑，或者是MQ之类的异步消息中间件，管道根本不关心具体传送的数据，所以与其叫哑管道，不如叫非智能管道（实际上我都不知道为什么会翻成哑管道，难以理解），智能端点就是相对ESB中的服务提供者只需要提供一种类型的服务，智能端点需要根据服务调用者的需求提供多种类型的服务以适应业务发展。也就是上述那些ESB所做的比如报文转换，比如数据转换等等统统是在服务提供端实现。
去中心化治理
- 去中心化管理数据，每个微服务管理其自有的数据库
- 基础设施自动化， 指自动化测试和自动化部署
- 容错设计，微服务架构中通常是一挂全挂
- 演进式设计
springcloud是一个解决微服务架构实施的综合性解决框架
若有收获，就点个赞吧
0 人点赞
