看点一：微服务产生的背景和过程
在数字化转型的大背景下，微服务正在成为企业未来架构的核心，很多互联网巨头都采用微服务方式构建业务应用。
微服务的产生背景源于单体架构无法满足互联网快速迭代的需要。伴随着业务和数据的增长，所有程序都运行在同一主机上，单体架构会导致应用程序的横向扩展会变得越来越吃力，成本越来越高。应用程序的复杂性逐渐增加以及功能越来越多，使得团队如果尝试引入新的框架技术或者对现有技术栈升级，通常会面临不小的风险。在这样的背景下，微服务出现了。
看点二：微服务的特点
微服务架构有三个特点，分别是 “微”、分布式、共享。
微服务的 “微” 体现在其单一职责和独立自治，微服务可以自己进行部署、升级、扩容等操作。
由于独立自治，它的第二个特点就是分布式，即微服务是去中心化的，服务之间是对等关系，然后用轻量级的这种通信将 API 能力共享出去。基于共享服务可以快速组装创新出新的能力。
微服务使大型的复杂应用程序可以持续交付与持续部署。每个服务都相对较小并容易维护。微服务可以独立服务、独立部署，更容易实验和采纳新的技术，也有着更好的容错性与可靠性。
但是不是所有的系统都要采用微服务架构。对于微服务来说，服务越小，独立性更好，但是相应的服务数量就越多。每个服务都需要独立的配置部署监控、日志收集等，成本呈指数级增长。
微服务经常使用异步编程、消息队列及并行处理，如果要求一个操作必须是同步且具有事物性，就需要管理好相关联服务及分布式事务操作。微服务的测试也比较困难，无论人工还是自动测试，通常都很难以一致的方式重现微服务应用环境。
作为一种分布式系统，微服务带来如网络延迟、容错性、消息序列化等一系列问题。当把传统的系统拆分成多个相互协作的独立服务后 ，随着服务数量的增多，如何清晰明了地展示服务之间的依赖关系，逐渐成为挑战。
因此要开发高质量的微服务，需要从组织流程、技术架构、平台工具、工程方法 4 个方面去保证。
看点三：微服务实施策略
微服务落地实施第一个是需要组建全功能小团队。团队需要围绕每个微服务的实施进行组织和团队间协作。团队还应该把关注点放在将他们实施的服务作为产品上，提供持续的支持，而不是一个离散的小项目，直接地对其实施的微服务负责。
第二，要有容器云平台和 CICD 全套工具链。
第三，要有指导方法，比如说基于 DDD 的设计方法和服务化设计演进方案。
第四，要有技术架构，例如微服务的治理框架。
看点四：业务微服务化设计全景图
2004 年，著名建模专家 Eric Evans 发表了 Domain-Driven Design: Tackling Complexity in the Heart of Software，书中提出了领域驱动设计 (简称 DDD) 的概念。DDD 是基于面向对象分析与设计的技术，对技术架构进行了分层规划，同时对每个类进行了策略和类型的划分。
微服务也是基于 DDD 的设计方法来指导全流程的设计。首先是通过需求分析，了解产品的定位和业务场景，然后进行领域设计，通过事件风暴、聚合设计、服务地图、分层模型进行业务流程的梳理和微服务的划分。
划分完之后，对每一个微服务进行对象的建模和技术架构的选型，最后进入到 DevOps 的迭代功能迭代开发。
看点五：微服务的治理
微服务的治理，其实是服务治理简史的梳理。从单体应用开始，单体应用没有服务的概念，不算是“服务治理”，复杂度来自于自身内部组件，由于组件的管理需要衍生出“组件治理”的需求，只需要维护组件和服务流程。
然后是 SOA 服务治理，企业 SOA 架构是对 ESB 总线进行整合。主要解决已有系统的整合（互联互通）问题。在技术实现及流程上企业 SOA 架构繁琐复杂、治理成本高。但其覆盖面广、涵盖企业 IT 各方面和 IT 治理重叠度高。SOA 的缺点是手工治理比较重大、自动化程度不足。
进入到互联网时代后，互联网服务化伴随业务拆分应运而生，主要解决业务快速响应及系统复杂性扩散问题，聚焦线上服务的生命周期治理，强调自动化。互联网服务化的实现五花八门，虽然有标杆却没有统一标准。
到了微服务时代，随着理论、技术、工具的进步，出现了微服务的治理平台。基于一些大的平台和框架，微服务和容器技术和敏捷开发它就紧密的结合在了一起。
微服务不仅仅是服务化架构的延伸，组织架构、管理策略、研发模式、测试、运维等领域都要做出响应的调整，为微服务架构的落地创造合适的“土壤”。这时，微服务时代就出现了线上线下一体、全生命周期的立体化治理和强调自动化、智能化的理念。这也是区别于互联网服务化的地方。
本期内容干货满满，是否意犹未尽？想学习云计算的更多内容吗？敬请锁定“深信服科技”公众号，云集技术学社还将邀请更多的专家，分享他们对云计算技术的理解和实践经验。
