微服务怎么整合成单体项目 微服务 单体应用

现在越来越多的项目设计都是微服务和分布式项目，大家是否真的理解了这方面的设计理念，和他们出现的优势呢，这期笔者结合我们早期的单体应用服务，和现在比较热门的微服务架构项目进行一些列对比，展示出他们各自的优缺点，以便大家思考。

单体应用

优势

• 简单粗暴，一个应用打包所有功能
• 本地开发调用方便，没有很长的调用链
• 本地函数调用，没有网络调用开销
• 线上查找问题相对简单一点

痛点问题

• 系统耦合度很高，导致开效率降低
• 随着需求和代码量激增，各个服务之间的边界模糊了
• 依赖于开发团队的个人水平
• 在开发某个新功能的时候，因为代码都是在一起的，回滚可能会影响其他功能点。
• 语言比较单一，在跨语言上支持力度不方便。
• 系统整体可靠性不高，其中一个功能点出现问题可能会导致整个服务无法使用。
• 系统不易于扩展部署
• 无法对于某个功能点，对其做服务器的扩展。整体的部署对于服务器的资源消耗有很大。

微服务架构

优势

• 系统的耦合度降低
• 模块之间按业务物理隔离了
• 系统整体可靠性变高
• 技术选型丰富，不同的服务模块可以利用不同的技术或语言来实现。
• 根据服务扩展部署
• 服务化之后解耦了业务

不足

• 部署会成为链路，因为服务之间相互关联，有些服务需要依赖其他服务启动后，才可以部署
• 本地开发和调试的时候同样是依赖其他服务，会变得很复杂
• 增加了网络开销，出现的问题难以定位问题来源
• 网络的之间调用不可靠
• 总结就是，微服务的开发，测试，部署，问题追踪等更加的复杂。

网络衍生问题

• 调用失败 的重试机制
• 疯狂调用的 限流措施
• 其中服务器挂掉后引起雪崩的 熔断措施
• 高并发情况下的 降级策略

分布式衍生组件工具

• 注册中心
  消息的注册和发现
• 配置中心
  多服务的统一配置
• 路由网关
  对调用者进行权限控制，和服务的限流降级等
• 链路追踪工具
  多服务之间的调用链路，对所有服务器做到全面监控
• 部署容器
  docker容器技术等。
• DevOps工具
  自动化部署，配合部署容器一起使用。

一些问题的解决策略

出现问题：

引入分布式链路追踪服务来定位问题

日志的查看：

引入ELK来方便日志的查看和分析问题。

老生常谈的SOA和微服务

SOA（Service-Oriented Architecture 面向服务的架构）

依赖于ESB企业服务总线进行交互，做的是 中心化

侧重点：
注重企业资源的重复利用

微服务（Microservice）

做的是 去中心化

侧重点： 应用级别的概念，应用的服务划分，使得服务之间便捷清晰，易扩展

彼此不冲突，都是面向服务，微服务对于服务应用的拆分更加注重一些，使得各服务边界更加清晰。而SOA更注重企业级别的资源和服务的使用。

所谓的分布式和集群

分布式:

我们目前所说的分布式 大多数都是指通过网络连接多个组件组成的系统。

集群:

一个组件存在多个实例构成的一个整体