微服务（Microservice）这个概念有一个鲜明的特点：一解释就懂，一问就不知，一讨论就打架。
作为一种架构概念，在提出的时候主要是为了将业务功能按某个层次拆分为一个个服务独立存在，从而实现解决方案的解耦。
也就是把一个单体应用，拆分为数个甚至数十个服务独立存在和部署，使成为一个个分散的应用。
彼此之间通过远程调用进行请求和返回，也就是你可以用Java开发这个服务，用go开发另一个服务，彼此可以独立开发，管理和迭代。
烂笔头不如一张图系列
一切脱离实际的解答都是扯淡（侵删）
如一个商城系统，按照业务功能进行服务划分:
可以把关于用户操作的业务单独为一个服务，实现用户登陆授权，鉴权，通知提醒。
可以把商品信息，上架，下架等单独为一个服务。
可以把支付单独为一个服务，实现多支付平台的接入，更细一层，还能把订单也单独为一个服务。
＂微＂需要的手足
网关: 举个例子，我们可以将其他服务进行物理上的隔离，只通过一个网关层统一接收用户请求，再分发打到请求的服务上，从而实现服务的安全和负载均衡的设计。
服务发现 : 就是有个篮子存在服务的信息，从而服务与服务之间可以互相知道怎么去找彼此，一般存放服务的请求地址，负载均衡方案等。比较流行的方案有许多，比如zookeeper，nacos，甚至redis。
服务调用: 服务与服务之间，虽然可以知道彼此的地址等信息，但调用彼此仍是需要考虑的问题，为了不同语言环境下的通用，一般是基于http的rest请求，更容易实现，灵活和被接受。同时还有使用消息中间件的异步通信方案，这里不展开说啦。
服务容错: 容错这个概念，简单说，就是你的服务出现某个问题，导致我在请求你的时候出现异常，导致我出了异常，或者被一次大并发打垮，导致调用我的服务也出了异常，另一个调用调用我的服务的服务也异常，从而出现一种雪崩效应，整个微服务都出了问题！所以为了避免这种非常非常可怕的事情，我们对服务需要做容错的方案，比如超时的设置，避免请求的积压，如异常的统一处理，避免无法识别异常出现的异常...
过分的＂微＂并不是完美
目前微服务可谓是最火热的架构思想，但概念这玩意是吸收的，而不是一味跟随着来的。
就想做个应用，明明只需要前后端分离，用户基数小，业务单一，那么就单体应用架构或者SOA便可以解决，就不需要硬要使用微服务进行设计。
常见的架构设计一般遵循三个标准:
1. 及时响应业务需求
2. 提升用户体验
3. 降低成本
我们应该为了敏捷的开发和部署而＂微＂，而不是追逐潮流而＂微＂。
在了解了微服务后，考虑实际情况，为了更好的实现产品价值而进行选择。
微服务，就是业务拆分，并不邪乎，勿盲目推崇
閱讀更多 居家程序員 的文章
