谈微服务

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文链接： https://blog.csdn.net/brytlevson/article/details/102662698

随着云化以及应用功能变得越来越频繁，整体式架构的缺点就显示出来了，还有一个庞大的整体式架构项目维护和扩展起来那真的是一点也不方便。这时候微服务的概念就出来了：微服务是将单一程序应用作为一小套服务组件来开发，每个服务之间在单独进程之间运行，通信主要用的是http请求以及模块导入。每个服务之间可以用不同的编程语言编写，并使用不同的数据存储技术。
说白了微服务就是一套架构风格。
微服务的特点：
各个服务之间解耦合
去中心化
互联网/内联网/网络更加成熟；
轻量级运行时技术的出现(node.js, WAS Liberty等)；
新的方法与工具(Agile, DevOps, TDD, CI, XP, Puppet, Chef…)；
新的轻量级协议(RESTful API接口, 轻量级消息机制)；
简化的基础设施：操作系统虚拟化(hypervisors), 容器化(e.g. Docker), 基础设施即服务 (IaaS), 工作负载虚拟化(Kubernetes,Spark…)等；
服务平台化(PaaS)： 云服务平台上具有自动缩放、工作负载管理、SLA 管理、消息机制、缓存、构建管理等各种按需使用的服务；
新的可替代数据持久化模型：如NoSQL, MapReduce, BASE, CQRS等；
标准化代码管理：如Github等。
异步机制：微服务往往使用异步编程、消息与并行机制，如果应用存在跨微服务的事务性处理，加快系统响应速度
当然也有一定的缺点：
每个服务之间没有特别明确的边界
开发的架构思想会有所不同，涉及到很多功能模块的拆分，所以拆分不当会造成开发困扰。
对开发团队的要求也比较高，比如说团队人员既管应用，也管数据库等等。
异步机制：微服务往往使用异步编程、消息与并行机制，如果应用存在跨微服务的事务性处理，其实现机制会变得复杂化。
很难全面测试，解决方法：做一些监测。
微服务需要一个更加显式的服务借口，对显示接口目前来说各个语言都是支持不太好的。