|
首先介绍一下微服务的由来： 官方地址： https:///articles/microservices.html 译文地址： https://mp.weixin.qq.com/s?__biz=MjM5MjEwNTEzOQ==&mid=401500724&idx=1&sn=4e42fa2ffcd5732ae044fe6a387a1cc3#rd 什么是微服务摘抄原文片段： In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.1234567复制代码类型：[java] 简而言之，微服务可以归纳为以下几点： 由一组小服务组成的应用，这一组服务往往提供特定的业务能力(业务维度) 往往拥有自己独占的进程，通过轻量级的通讯协议进行通讯，比如http(技术维度) 能够独立部署，并且具有完全的自动化的部署能力(运维纬度) 极小化的集中式的服务管理能力(平台管控维度) 可以使用任何的开发语言和数据库技术(技术选型维度) 巨石服务VS微服务下图为巨石服务和微服务的比较图： 所谓巨石服务就是我们平时所见到的集合所有功能于一个进程中的项目。我们知道，一个项目中不同模块的流量是不一样的。 就拿电商项目来说，当下单服务和搜索服务流量较大时，会影响其它模块的接口访问，那么这时候单节点支撑不了时，就需要做集群。 虽然该方案可以解决一部分问题，但是有一个很致命的问题，友好颗粒度不够，容易造成资源浪费。那么这时候就需要转换成微服务，一个模块对应一个服务进程，哪个服务压力大就对哪个服务进行扩容，这样灵活度就比巨石服务来得高，也不会造成资源的浪费。 微服务架构图SpringCloud架构图 Dubbo架构图 SpringCloud和Dubbo作为大家熟知的微服务产品，也是面试最常问的两大微服务框架。从架构图中就可以清晰的知道，在微服务架构下，服务与服务之间的关系变的复杂很多，这也意味着在享受微服务架构带来好处的同时，也需要付出相应的代价。 当然，除了Dubbo和SpringCloud产品外，还有其它优秀的微服务产品可供选择，BaiduRPC、gRPC、SofaRPC等。 微服务架构的优势
微服务架构的缺点
在《Microservices-NotAFreeLunch!》文章中也提出了微服务的潜在问题。 地址： http:///blog/2014/4/8/microservices-not-a-free-lunch.html |
|
|
