“微服务“这一概念出现于2012年,是因软件作者Martin Fowler而流行。
微服务将单一应用程序分解为多个业务服务。它的出现带来了下列变化：
- 单个系统按照不同业务进行分解（服务组件化），业务内部的逻辑更趋向于集中，提高了代码的复用性，减少了代码rǒng冗余，提高了业务整体系统性能，
- 微服务网关，提高了系统安全性，隔离了客户端的直接连接
- 注册中心，通过注册中心建立起个服务之间的联系，从而控制服务之间的联系方式
- 配置中心，通过不同的服务共享其配置，并可以及时同步到相应服务上
- 服务易于扩展和延申，降低了服务器的成本
影响：
- 增加了运维部署的时间、管理、测试、通讯成本
- 排错的时间成本、日志记录成本
- 增加了不同服务之间的故障概率
- 增加了服务之间管理难度和成本
- 服务之间的事务一致性得不到保障
- 不同服务之间的开发者会增加开发学习成本，团队沟通成本增加。
适用于：
如果是大型项目，那么微服务是很适合的。比如项目中具备了完整的企业全链式系统，一个庞大的组织。大型项目具备的特点有系统架构复杂、业务模块多、牵连范围广。
如果是小型项目，一个简单的商城系统或小程序，那么没必要使用微服务拆分。
解决微服务带来的影响，给您提供以下建议：
- 不间断的架构技术培训，可以给开发人员减少沟通成本
- 条理清晰的产品、技术文档，可以减少服务之间的学习成本
- 统一有序的服务发布部署，提高系统发布的稳定性
- 服务之间的监控，为分散的服务的故障排查提供了方便
- 服务共享锁，多线程的资源访问安全性提高，减少资源的死锁
- 资源锁定，当进行事务一致性处理时，处理前应该对需要的资源进行锁定，处理成功或失败之后释放该资源，避免数据出错
- 对于接口，有添加的正向过程，就要有失败的逆向过程。
微服务网关
常规情况下PC端UI页面连接的是API程序，加入网关之后，UI页面先连接的是网关，一个网关可能只有一个域名，通过网关内部配置连接对应的服务。
比如：访问www.baidu.com?xxx=xxx，会进入资源网关，网关统一域名就是www.baidu.com，网关会根据url请求参数进行解析，然后内部调用响应的服务或者api，网关的本身也可以是一个APi或者服务。但网关实际上就是一个配置转发。
这样的好处是，客户端ui无法知道真正连接的是哪个服务处理的。并且在流量大的时候，网关也可以根据流量在不同服务之间进行切换。对服务与客户端的连接进行控制。
注册中心
注册中心像是应用的认证，不同的服务只有在一个注册服务上注册了的，才能进行调用。注册中心就是服务之间的通讯录。
配置中心
就是服务或网站web.config的配置文件，只不过它是把相同的配置放在一个位置，或者是把每个服务配置都放在一个位置。配置中心负责把配置同步到对应的应用上面。
一个完整的微服务实际上还需要一个方便管理的发布系统，通过git拉取、项目编译、生成docker发布包，同步到对应的linux服务器上。
还需要一个监控系统比如Cat，可以监控每个服务之间的心跳，也就是服务与服务之间是否连接成功的一个状态。监控系统可以随时看到sql延迟、资源死锁、服务无法连接、IO瓶颈、网络中断、序列化异常、数据并发、雪崩、程序异常、事务已牺牲到另一资源上等状态和http上下文日志情况。不仅如此还要能看到某一时刻的数据吞吐量，服务消费状态等。