微服务架构诞生以来，在各种演讲、文章、书籍上所出现的频率之高，足以看出它对软件架构领域带来的巨大影响。经过这两年的快速普及，微服务的实践已经在越来越多的组织和企业内部得以推广和运用。

微服务架构的演进，作为一种架构模式，微服务将复杂系统切分为数十乃至上百个小服务，每个服务负责实现一个独立的业务逻辑。这些小服务易于被小型的软件工程师团队所理解和修改，并带来了语言和框架选择灵活性，缩短应用开发上线时间，可根据不同的工作负载和资源要求对服务进行独立缩扩容等优势。另一方面，当应用被拆分为多个微服务进程后，进程内的方法调用变成了了进程间的远程调用。引入了对大量服务的连接、管理和监控的复杂性。让我们来回顾一下微服务架构的发展过程。在出现服务网格之前，我们最开始在微服务应用程序内理服务之间的通讯逻辑，包括服务发现、熔断、重试、超时、加密、限流等逻辑。

微服务的优点：将应用程序分解为不同的更小的服务的好处是，它改进了模块化，使应用程序更容易理解、开发、测试，并且更能抵御体系结构的侵蚀。它还通过允许小型自治团队开发、部署和部署来并行化开发。简单来说，微服务架构基本符合我们拆解问题的方式 -- 把一个复杂问题拆成多个简单的问题，这个复杂问题就是在开发软件过程中的复杂度问题，但微服务的拆解是基于业务模块的。

总结一下：独立性，这里的独立性指的是各个服务的开发、测试、部署都相互独立。比如：我们的用户服务就可以拆分作为一个单独的服务，而它的开发也不用依赖于其他服务。如果我们的用户量大，我们可以很容易的对其进行负载。敏捷性，当一个新需求出现时，特别是在一个庞大的项目系统中，你得去考虑各方的问题，兼容性，影响度等等，而使用微服务则可以省掉很多这些废时又烧脑的环节。实现更灵活，在以前的项目开发中，基本上一个大的项目都基于同一语言的技术架构来开发，这样的限制很大 。而使用微服务拆分后的各服务之间没有这个限制，你只需要保证对外提供的接口是正常可用的就行。至于你是使用什么语言、什么框架通通不用关心。

未来的几年，相信会有更多的企业将目光聚焦在如何有效地将微服务落地这个核心问题上。微服务的概念看似浅显易懂，但实际上却与架构演进、领域建模、持续交付及DevOps等多个维度的方法论与实践密切相关。在一个分布式系统中，这部分逻辑比较复杂，为了为微服务应用提供一个稳定、可靠的基础设施层，避免大家重复造轮子，并减少犯错的可能，一般会通过对这部分负责服务通讯的逻辑进行抽象和归纳，形成一个代码库供各个微服务应用程序使用。“微服务的落地需要经过全面的考察和完善的试验，并不是每个场景都适合使用微服务架构，也不是每个企业都有能力或者精力去面对这些挑战。

最后，和大家探讨一下微服务拆分的通用策略：先从整体来分析业务的特性或者进行大模块切分，比如基础服务模块、社区业务模块、分发业务模块等。可以考虑先针对某些大模块（而不是全部）进行切分，成功后再复用到其他模块。遵循先少后多、先粗后细的原则，千万不要试图一次过拆分完成，那基本是不可能完成的任务。拆分时要考虑的因素至少包括：业务的独立性及发展趋势、微服务的研发维护及质量流程、团队特点及技术因素等。

中培伟业建立了完善的服务体系，即严格按照ISO9001国际质量管理体系标准及咨询服务业标准规范，建立了标准化的服务流程，对培训、咨询服务实施全过程质量控制，关注顾客反馈，从而使客户的需求得以实现。据该机构相关老师介绍，机构多年来立足实际，稳定发展，每年分别举办微服务架构设计公开课程和企业内训与咨询100余场，并取得了不错的市场反响。