微服务的出现

“微服务“这一概念出现于2012年,是因软件作者Martin Fowler而流行。

微服务将单一应用程序分解为多个业务服务。它的出现带来了下列变化

1. 单个系统按照不同业务进行分解（服务组件化），业务内部的逻辑更趋向于集中，提高了代码的复用性，减少了代码rǒng冗余，提高了业务整体系统性能，
2. 微服务网关，提高了系统安全性，隔离了客户端的直接连接
3. 注册中心，通过注册中心建立起个服务之间的联系，从而控制服务之间的联系方式
4. 配置中心，通过不同的服务共享其配置，并可以及时同步到相应服务上
5. 服务易于扩展和延申，降低了服务器的成本

影响

1. 增加了运维部署的时间、管理、测试、通讯成本
2. 排错的时间成本、日志记录成本
3. 增加了不同服务之间的故障概率
4. 增加了服务之间管理难度和成本
5. 服务之间的事务一致性得不到保障
6. 不同服务之间的开发者会增加开发学习成本，团队沟通成本增加

适用于

　　如果是大型项目，那么微服务是很适合的。比如项目中具备了完整的企业全链式系统，一个庞大的组织。大型项目具备的特点有系统架构复杂、业务模块多、牵连范围广。

如果是小型项目，一个简单的商城系统或小程序，那么没必要使用微服务拆分。

解决微服务带来的影响，给您提供以下建议

1. 不间断的架构技术培训，可以给开发人员减少沟通成本
2. 条理清晰的产品、技术文档，可以减少服务之间的学习成本
3. 统一有序的服务发布部署，提高系统发布的稳定性
4. 服务之间的监控，为分散的服务的故障排查提供了方便
5. 服务共享锁，多线程的资源访问安全性提高，减少资源的死锁
6. 资源锁定，当进行事务一致性处理时，处理前应该对需要的资源进行锁定，处理成功或失败之后释放该资源，避免数据出错
7. 对于接口，有添加的正向过程，就要有失败的逆向过程。

微服务网关

　　常规情况下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上下文日志情况。不仅如此还要能看到某一时刻的数据吞吐量，服务消费状态等。