传统与微服务

微服务架构的优势

• 每个服务都比较简单，只关注于一个业务功能。

• 微服务架构方式是松耦合的，可以提供更高的灵活性。

• 微服务可通过最佳及最合适的不同的编程语言与工具进行开发，能够做到有的放矢地解决针对性问题。

• 每个微服务可由不同团队独立开发，互不影响，加快推出市场的速度。

• 微服务架构是持续交付(CD)的巨大推动力，允许在频繁发布不同服务的同时保持系统其他部分的可用性和稳定性。

微服务架构的缺点

• 运维开销及成本增加：

整体应用可能只需部署至一小片应用服务区集群，而微服务架构可能变成需要构建/测试/部署/运行数十个独立的服务，并可能需要支持多种语言和环境。这导致一个整体式系统如果由20个微服务组成，可能需要40~60个进程。

• 必须有坚实的DevOps开发运维一体化技能：

开发人员需要熟知运维与投产环境，开发人员也需要掌握必要的数据存储技术如NoSQL，具有较强DevOps技能的人员比较稀缺，会带来招聘人才方面的挑战。

• 隐式接口及接口匹配问题：

把系统分为多个协作组件后会产生新的接口，这意味着简单的交叉变化可能需要改变许多组件，并需协调一起发布。在实际环境中，一个新品发布可能被迫同时发布大量服务，由于集成点的大量增加，微服务架构会有更高的发布风险。

• 代码重复：

某些底层功能需要被多个服务所用，为了避免将“同步耦合引入到系统中”，有时需要向不同服务添加一些代码，这就会导致代码重复。

• 分布式系统的复杂性：

作为一种分布式系统，微服务引入了复杂性和其他若干问题，例如网络延迟、容错性、消息序列化、不可靠的网络、异步机制、版本化、差异化的工作负载等，开发人员需要考虑以上的分布式系统问题。

• 异步机制：

微服务往往使用异步编程、消息与并行机制，如果应用存在跨微服务的事务性处理，其实现机制会变得复杂化。

• 可测性的挑战：

在动态环境下服务间的交互会产生非常微妙的行为，难以可视化及全面测试。经典微服务往往不太重视测试，更多的是通过监控发现生产环境的异常，进而快速回滚或采取其他必要的行动。但对于特别在意风险规避监管或投产环境错误会产生显著影响的场景下需要特别注意。

微服务架构的取舍

• 在合适的项目，合适的团队，采用微服务架构收益会大于成本。
• 微服务架构有很多吸引人的地方，但在拥抱微服务之前，也需要认清它所带来的挑战。
• 需要避免为了“微服务”而“微服务”。
• 微服务架构引入策略 – 对传统企业而言，开始时可以考虑引入部分合适的微服务架构原则对已有系统进行改造或新建微服务应用，逐步探索及积累微服务架构经验，而非全盘实施微服务架构。

总结

最后总结一下，其实微服务就是将原本非常臃肿的单体应用拆分成若干个细粒度的小型服务，独立进行部署（现在的流行得益于docker容器技术的飞速发展），单独开发、测试、运维等。
需要特别指出的一点，微服务并不是说拆分得越细越好，而是要贴合业务，考虑整个系统的质量属性需求，根据实际情况进行横向拆分和纵向拆分。因为拆分得太细，那服务间的交互通讯以及运维工作成本将大大提高，拆分得太粗，又达不到微服务的效果。综合以上的情况，一般情况下首先是针对公共模块的内容进行收集整理，打包成通用的服务，即横向拆分；另外还需要考虑不同业务之间的耦合度，将相对独立的“服务集”拆分到不同的服务中，这就是我所理解的纵向拆分。所以现场场景下都是需要横向拆分与纵向拆分相结合使用，才能让微服务达到最好的效果。