贺权7
微服务概念
微服务，是把一个复杂的应用拆分成多个小的服务，每一个服务可以被独立部署，可以独立对外提供服务调用，各个服务之间是松耦合的，每一个服务很容易做局部修改。
微服务可以带来独立部署、扩容缩容、故障隔离、自由使用开发语言等有点，但是也会带来分布式事务、监控、自动化部署等挑战。
优点
服务的拆分，可以简化服务，因此单个微服务更容易开发和维护。
每个微服务可以独立部署，升级更新的时候不用协调其他服务端配合做操作。
因为服务和服务之间是松耦合的，因此微服务可以独立的升级、进化、扩展。
微服务之间的数据传输都是接口调用，因此每个微服务可以采用不同的开发语言。
服务可以最大程度地重用。
缺点
微服务虽然功能单一，但是随着不断的扩展，微服务也容易变成大的服务，可能还会面临拆分的问题。
微服务是分布式的，由此会带来固有的复杂性。
增加了测试的复杂程度。
部署一个微服务的服务简单，但是通常一个微服务都是由大批服务构成。如果没有自动化部署方案，是一件很痛苦的事儿。
同时对监控的要求很高。
什么时候选择微服务
不结合实际情况的架构设计都是耍流氓；架构设计不用追求高大上，只要能满足业务需求，便是好架构。
首先能把微服务用好，首先是有一些基础条件的，比如：
快速配置和快速部署：在很短的时间内可以配置好一台服务器并且把应用部署好。这些都需要云平台、容器技术的支撑。
自动化的运维和监控；不仅仅是服务器性能的监控，还有接口的监控，服务的链路追踪。
数据可以做到独立，如果多个微服务依然访问的是同一个数据库，那么就不是微服务。
持续改进的团队组织。
所有的基础性工作做好了之后，再去根据业务进行服务的拆分，同时也要结合业务的压力，加入业务压力不大，完全几个系统就能搞定的时候，就不一定非得用微服务。
微服务架构不是一步就建好的，都是被业务一步一步地逼出来的。
会点代码的大叔
只要是单一系统应付不了的应用都可以使用微服务！
传统的集中式系统，所有的业务代码全部写在一个系统中，也只需要通过本地调用接口，但是随着业务量变大，单个系统无法处理过来，又存在单个服务宕机引起系统不可用的问题！
这个时候就需要拆分服务，让服务分布在不同的机器上，解耦服务的同时，让单个服务能有更加稳定的特性！
比如说一个电商系统，包括前端购买页面，后台运营页面等，做成sso单点登录，提供对外服务！会员模块，订单模块，积分模块等分别做成不同的服务，分布在不同的服务器上，保证单个服务宕机的时候，不影响别的服务正常运行！
服务间使用http调用，或者使用ribbon，feign等实现客户端的负载均衡！保证服务间的解耦和数据通信！
微服务作为现在web服务开发中非常流行的架构，由于其稳定性，快速，独立部署的特性得到大量使用，可以说随着业务的不断发展，微服务必将大放光彩！
当然，微服务也存在不足，不仅需要大量的机器成本，在运维方面也存在很大的挑战，同时，因为分布的原因，数据一致性，共享问题都是需要严格考虑的！
使用了两年微服务，也遇到了很多坑，如果你也遇到了微服务问题，欢迎来打扰！
此生唯一
最近几年微服务很火，大家都在建设微服务，仿佛不谈点微服务相关的技术，都显得不是那么主流了。
近几年见识到身边朋友的很多公司和团队都在尝试进行微服务的改变，但很多团队并没有实际微服务踩坑经验，很多团队甚至强行为了微服务而去微服务，最终写成一个大型的分布式单体应用，就是改造后的系统既没有微服务的快速扩容，灵活发布的特性，也让原本的单体应用失去了方便开发，部署容易的特性（项目拆为多份，开发部署复杂度都提高了），不得不说是得不偿失。
想要了解微服务的适合场景，必须要先搞清楚以下几点内容：
一：什么是微服务？为什么要用微服务？
二：微服务解决什么问题，又引入了什么问题？
三：使用微服务应该遵循哪些原则？
以上问题了解清楚后，我想你应该微服务的适用场景了。下面这篇文章个人觉得写得挺不错的，推荐你查阅一下，希望我的回答能给你提供帮助。谢谢
https://www.cnblogs.com/xiao2shiqi/p/11298663.html
