微服务架构的思考

一、单体架构存在的问题

1、编译、部署困难

对一个比较大的单体应用来说，每次项目在部署和构建的时候，耗时非常多；而且更糟糕的时候，当打包失败后，还得重来...很多时候都郁闷的想砸了显示器...

2、代码分支管理困难

福永的代码模块由多个团队共同维护修改，代码merge的时候总会发生冲突。代码merge一般在网站发布的时候，和发布等问题相互纠结在一起，顾此失彼，每次发布都要半夜三更。

3、数据库链接耗尽

句型的应用、大量的访问，必然需要将这个应用部署在一个大规模的服务器集群上，应用于数据库的连接通常使用数据库连接池，以每个应用10个连接计算，一个数百台服务器集群的应用将需要在数据库上创建数千个连接，数据库服务器上，每个连接都会占用一些昂贵的系统资源，以至于数据库缺乏足够的系统资源进行一般的数据库操作。

4、新增业务困难

想要子啊一个已经乱码般的系统中增加新业务，维护旧功能，困难可想而知。

一脚踩进去，发现全是雷，什么都不敢碰，一不小心就容易产生新的bug。



二、什么是微服务架构

从一中可以看出传统单体应用的bug。现在系统一般都是微服务架构，这里解释下什么是微服务架构。它一种架构风格，将一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。



三、微服务架构的技术点



服务的注册与发现、身份验证与授权、服务的伸缩控制、反向代理与负载均衡、路由控制、流量切换、日志管理、性能度量监控和优化、分布式跟踪、过载保护、服务降级、服务部署与版本升级策略支持、异常处理。关键点如下图：



四、微服务架构的优势



• 可扩展性:在增加业务功能时，单一应用架构需要在原先架构的代码基础上做比较大的调整，而微服务架构只需要增加新的微服务节点，并调整与之有关联的微服务节点即可。在增加业务响应能力时，单一架构需要进行整体扩容，而微服务架构仅需要扩容响应能力不足的微服务节点。

• 容错性:在系统发生故障时，单一应用架构需要进行整个系统的修复，涉及到代码的变更和应用的启停，而微服务架构仅仅需要针对有问题的服务进行代码的变更和服务的启停。其他服务可通过重试、熔断等机制实现应用层面的容错。

• 技术选型灵活:微服务架构下，每个微服务节点可以根据完成需求功能的不同，自由选择最适合的技术栈，即使对单一的微服务节点进行重构，成本也非常低。

• 开发运维效率更高:每个微服务节点都是一个单一进程，都专注于单一功能，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，每个微服务可由一个小规模团队或者个人完全掌控，易于保持高可维护性和开发效率。