回答关于微服务的几点老板关心问题
单体系统在初期可以实现比较方便地开发与使用，但是随着系统的发展，维护成本变大，且难以控制（当一个系统业务复杂且架构设计不合理，同时以前的开发者之间没有什么规范的时候，后续新人对于功能的修改、维护、完善都必须建立在对系统整体业务的把握上，这也对开发人员提出了更高要求）。
引进微服务架构体系作为后续主体架构，将不同的模块拆分成多个不同的服务，服务能够实现独立的部署与扩展，且不同的服务都运行在自己的进程中，由于部署存在稳定的边界，这样每个服务的更新都不会影响到其他服务的运行，也更方便后续整体架构的水平扩展。同时平衡需求的多变和软件工程本身的技术复杂性的矛盾，从而在应用开发小团队中推行敏捷开发开发模式。
单体架构是将所有业务功能全部集中在一个系统服务中，如果某个业务突发请求，或者异常，可能会导致整个系统宕机。
微服务体系中，会将不同的业务划分成不同的服务，各个服务会使用多个服务进行负载、容错、隔离。如果某个服务宕机，不会影响到整个系统的正常运行。
代码的执行效率与算法和设计有关系。微服务只解决了业务的划分之后服务治理与服务调用，对业务代码的执行效率不会有明显的改善，但是在改造的过程中，会逐步修复算法与设计的问题。
微服务可以根据业务情况，对高并发业务或者需要高保障的业务进行快速的横向扩容。
微服务以组件化的形式存在，可以根据公司不同的业务场景，满足各种定制化需求，快速交付。
微服务对后续PaaS平台的研发和支持提供了基础技术保障。
由于微服务都是运行在独立的容器中，相比ECS，大大节约了CPU与内存的使用率。
对资源的要求相对单体系统来说整体降低。
单体架构只需要一个独立的pod容器，但是在微服务中，每个独立服务都需要一个独立的pod容器。
独立服务的容错、负载（一个业务服务运行在多个进程/容器中），则需要消耗更多的系统资源。
在微服务体系中，资源与容错能力是成正比的。容错能力越强，则消耗的资源越多。
微服务体系物理架构在后续水平扩展方面可减少服务器数量和降低对服务器配置要求（高频/高可用微服务和低频/低可用微服务可分别部署至不同配置的服务器上。
微服务体系中每个服务都可以独立部署（高内聚低耦合），这样每个服务的更新都不会影响到其他服务的运行或影响范围可控，也更方便后续整体架构的水平扩展。
对于运维人员的要求： 掌握全链路监测、灰度发布，掌握基础微服务知识等相关能力。
对于测试人员的要求： 混沌测试（全链路测试）。
微服务架构体系加持续集成方案带来的预期收益主要有：
