微服务架构的软件运行可能存在哪些问题？

如果大家了解微服务和分布式服务器架构等技术的话，那么对于如何解决系统运行中出现的BUG造成的破坏和损失这些问题也应该有自己独到的见解吧。
今天，电脑培训>

微服务的系统架构开发方式相信大家应该不陌生了吧，在前几期的文章中我们也对微服务的架构方式做了一个简单的介绍。今天，昌平北大青鸟就来对比一下，微服务与传统单一服务架构的区别。

1如何理解微服务，简要说明您所理解的微服务是什么

微服务，这个词语其实是一次听说，我search了下定义，然后恍然明白，其实所谓的微服务，用更通俗接地气的词语来定义和描述的话，就是敏捷+模块的服务架构体系，如何解释敏捷，原来的亚马逊CEOBezos提出来的2pizza就是微服务系统架构的鼻祖，2pizza意思就是所有参与人从设计、开发、测试、运维所有人加起来只需要2个披萨就够了(应用自网上资料)，所以你能知道，既然要求敏捷，那要快并且高效，就要有模块化的思维方式，在汽车行业，如今大众，丰田都提倡模块化造成体系，不仅高效，而且很多可移植，在IT行业，这种模块化的思路也是，不仅代码可移植，如同乐高积木进行横向功能叠加，而且基于模块化的微服务，在运维方面，也是自成体系，不仅能减少模块的测试压力和成本，后我认为这个微服务还是符合当下资源高效利用的政策的，很多系统逐渐从大而全变成小而精，对于开发，运维等等也是如此，微服务就非常符合这个命题。

2与传统单一服务架构相比，在实战环境下，各自的优劣都有哪些

我认为存在即合理，没有所谓哪个好，只有哪个更合适，或者在当下需求和长期规划下，在不同阶段，何种架构更性价比高，对于单一架构体系，我认为复杂性高，接口冗余，稳定性中等是其特征，你可以说这是缺点，但是我认为对于比如大型金融架构，比如我所在的行业，这种soa的架构体系是主流，单一服务架构优势在于下属模块的差异度比较少，品类单一，规划比较完整，属于有了宏观架构和愿景进行搭建的方式，而微服务更适合互联网行业，快速部署，已经对于新技术的欢迎和迭代，是微服务的佳实践场所

3如果您考虑部署微服务，在业务部署过程中会遇到哪些关键挑战

主要是在金融行业，如果在已有的单一架构系统体系中，采用微服务的部署方式，与原来系统的耦合以及接口是要好好考虑的，要不然会出现四不像，既没有了原来大型单一系统架构的优势，微服务的快速，高效和低成本也会体现不出其好的效果，还有就是我认为即使是模块化的微服务部署，在能力范围之内要选择好不同模块的耦合和类型选择，否则百花齐开虽然漂亮，但是纵向升级以及进行整合还是非常让开发和运维的人绞尽脑汁的。

一个“微服务”是在一个语境下、一个背景下才有意义的词，尝试独立去定义或解释它是说不清楚的。

微服务架构是一种架构风格（或叫架构模式）、以及一组成功架构实践的总称。有时也代表一种架构思想。
微服务架构就是：以一组“按领域功能解耦的、彼此之间以轻量级通讯框架交互的、可独立开发/测试/发布/部署/升级和替换的、较小粒度的组件”的方式构建应用的架构模式！

1、 按领域功能边界解耦

2、 轻量级通信框架

3、 独立性、自治

4、 小粒度

5、 基础设施自动化，部署一个应用/单元，和部署100个应用/单元，没有显著差别（部署时间、人力等） 《一组成功实践》

6、 面向失败的设计

7、 持续演进