回答关于微服务的几点老板关心问题

单体系统在初期可以实现比较方便地开发与使用，但是随着系统的发展，维护成本变大，且难以控制（当一个系统业务复杂且架构设计不合理，同时以前的开发者之间没有什么规范的时候，后续新人对于功能的修改、维护、完善都必须建立在对系统整体业务的把握上，这也对开发人员提出了更高要求）。

引进微服务架构体系作为后续主体架构，将不同的模块拆分成多个不同的服务，服务能够实现独立的部署与扩展，且不同的服务都运行在自己的进程中，由于部署存在稳定的边界，这样每个服务的更新都不会影响到其他服务的运行，也更方便后续整体架构的水平扩展。同时平衡需求的多变和软件工程本身的技术复杂性的矛盾，从而在应用开发小团队中推行敏捷开发开发模式。

1、开发效率能提高吗？

• 在单体架构中，随着业务的发展，代码会越来越多，变得臃肿，编译、启动、打包、发布会变得越来越慢。
• 一个小功能的改动，重启都需要等待几分钟，导致很多的时间会浪费在这个过程中。
• 由于业务的变化性较高，使得各个业务的代码交互变得复杂，如果维护不当，会导致这些代码难以维护。 如果进行维护，就算只改动了一个小功能，也可能会影响到N个模块业务。
• 在微服务的体系下，将不同的业务层划分成各个不同的业务模块，使得模块间的耦合度降低，方便维护。
• 每个业务模块独立成一个微服务，由不同的人员（团队）来维护，达到可以独立开发和独立部署。
• 分工明确，代码逻辑清晰、代码量小，可维护性高，整体提高开发效率。

2、产品质量能提高吗？

单体架构是将所有业务功能全部集中在一个系统服务中，如果某个业务突发请求，或者异常，可能会导致整个系统宕机。

微服务体系中，会将不同的业务划分成不同的服务，各个服务会使用多个服务进行负载、容错、隔离。如果某个服务宕机，不会影响到整个系统的正常运行。

3、代码的执行效率能提高吗？

代码的执行效率与算法和设计有关系。微服务只解决了业务的划分之后服务治理与服务调用，对业务代码的执行效率不会有明显的改善，但是在改造的过程中，会逐步修复算法与设计的问题。

4、可扩展性如何？支持灵活的二次开发吗？以什么形式来支持呢？

微服务可以根据业务情况，对高并发业务或者需要高保障的业务进行快速的横向扩容。

微服务以组件化的形式存在，可以根据公司不同的业务场景，满足各种定制化需求，快速交付。

微服务对后续PaaS平台的研发和支持提供了基础技术保障。

5、服务器成本如何？与现在是持平还是更节省？还是更高？

由于微服务都是运行在独立的容器中，相比ECS，大大节约了CPU与内存的使用率。

对资源的要求相对单体系统来说整体降低。

单体架构只需要一个独立的pod容器，但是在微服务中，每个独立服务都需要一个独立的pod容器。

独立服务的容错、负载（一个业务服务运行在多个进程/容器中），则需要消耗更多的系统资源。

在微服务体系中，资源与容错能力是成正比的。容错能力越强，则消耗的资源越多。

6、后续的运维成本如何？

微服务体系物理架构在后续水平扩展方面可减少服务器数量和降低对服务器配置要求（高频/高可用微服务和低频/低可用微服务可分别部署至不同配置的服务器上。

微服务体系中每个服务都可以独立部署（高内聚低耦合），这样每个服务的更新都不会影响到其他服务的运行或影响范围可控，也更方便后续整体架构的水平扩展。

对于运维人员的要求： 掌握全链路监测、灰度发布，掌握基础微服务知识等相关能力。

对于测试人员的要求： 混沌测试（全链路测试）。

微服务架构体系加持续集成方案带来的预期收益主要有：

• 系统水平扩展能减少应用服务器需求数量和降低对服务器的性能要求；
• 快速响应业务部门的需求（系统短周期开发，测试，发布迭代的敏捷开发模式）；
• 相对单体系统降低开发人员的开发成本（微服务功能原子化）及管理成本（持续构建，静态代码检测，部署自动化）；
• 系统水平扩展更便捷（子系统以微服务热发布集成）；
• 系统稳定性更好（前后端分离，服务流量控制，服务健康检查，服务调度可监控及可追溯）。