在过去 8 年智慧城市的建设过程中，研发和交付了很多的大型项目，踩过很多的坑，趟过很多的雷，深受传统建设方法之苦，也深深被微服务架构带来的好处所感动，我们也将在微服务架构这条路的继续前行。在这里，将我们研发过程中的一些思考和心得分享给大家，供大家参考。
也许，在不久的将来，软件开发只需要组装，不再需要从头开发。
什么是微服务架构？
形像一点来说，微服务架构就像搭积木，每个微服务都是一个零件，并使用这些零件组装出不同的形状。通俗来说，微服务架构就是把一个大系统按业务功能分解成多个职责单一的小系统，并利用简单的方法使多个小系统相互协作，组合成一个大系统。
如果学科派一点，微服务架构就是把因相同原因而变化的功能聚合到一起，而把因不同原因而变化的功能分离开，并利用轻量化机制（通常为 HTTP RESTful API）实现通信。
追本溯源，Martin Folwer 对微服务架构的定义是：
微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相协作（通常是基于 HTTP 协议的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，对具体的服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建 。（摘自王磊先生的《微服务架构与实践》）
对于我个人，我更喜欢一种延续性的解释，微服务架构 ≈ 模块化开发 + 分布式计算。不管微服务架构的定义怎么样，都是在描述一个核心思想：把大系统拆分成小型系统，把大事化小，以降低系统的复杂性，从而大幅降低系统建设、升级、运维的风险和成本。
顺带提一下，亚马逊创始人 Jeff Bezos 在 2002 年就说过：所有团队的模块都要以 Service Interface 的方式将数据和功能开放出来。不这样做的人会被炒鱿鱼。这才是思路超前的大牛。
需要注意的是 “微服务” 与 “微服务架构” 是有本质区别的。“微服务”强调的是服务的大小，它关注的是某一个点。而“微服务架构”则是一种架构思想，需要从整体上对软件系统进行通盘的考虑。
Chris Richardson 说：“微服务”是一个很糟糕的名字，它导致开发人员创建了许多粒度很小的服务，每个服务拥有一个单独的 REST 端点。不仅如此，这个名字还暗示了微服务在开发者心目中的重要位置。例如，人们会说“我们可以用微服务来解决这个问题”；我也看到了越来越多的“某某微服务框架”，而实际上，这些框架跟微服务架构不一定有太多联系，它们只是简单的 Web 框架。使用“微服务架构”这个名字会更恰当些。它是一种架构风格，它把一系列协作的服务组织成一个系统来支撑业务。
常见的微服务组件及概念
服务注册，服务提供方将自己调用地址注册到服务注册中心，让服务调用方能够方便地找到自己。
服务发现，服务调用方从服务注册中心找到自己需要调用的服务的地址。
负载均衡，服务提供方一般以多实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点。并且，节点选择的工作对服务调用方来说是透明的。
服务网关，服务网关是服务调用的唯一入口，可以在这个组件是实现用户鉴权、动态路由、灰度发布、A/B 测试、负载限流等功能。
配置中心，将本地化的配置信息（properties, xml, yaml 等）注册到配置中心，实现程序包在开发、测试、生产环境的无差别性，方便程序包的迁移。
API 管理，以方便的形式编写及更新 API 文档，并以方便的形式供调用者查看和测试。
集成框架，微服务组件都以职责单一的程序包对外提供服务，集成框架以配置的形式将所有微服务组件（特别是管理端组件）集成到统一的界面框架下，让用户能够在统一的界面中使用系统。
分布式事务，对于重要的业务，需要通过分布式事务技术（TCC、高可用消息服务、最大努力通知）保证数据的一致性。
调用链，记录完成一个业务逻辑时调用到的微服务，并将这种串行或并行的调用关系展示出来。在系统出错时，可以方便地找到出错点。
支撑平台，系统微服务化后，系统变得更加碎片化，系统的部署、运维、监控等都比单体架构更加复杂，那么，就需要将大部分的工作自动化。现在，可以通过 Docker 等工具来中和这些微服务架构带来的弊端。 例如持续集成、蓝绿发布、健康检查、性能健康等等。严重点，以我们两年的实践经验，可以这么说，如果没有合适的支撑平台或工具，就不要使用微服务架构。
一般情况下，如果希望快速地体会微服务架构带来的好处，使用 Spring Cloud 提供的 服务注册（Eureka）、服务发现（Ribbon）、服务网关（Zuul） 三个组件即可以快速入门。其它组件则需要根据自身的业务选择性使用。
那么，我们什么时候需要采用微服务呢？
我个人的经验来看，我认为有三种场景可以考虑使用微服务。
规模大（团队超过 10 人）
业务复杂度高（系统超过 5 个子模块）
需要长期演进（项目开发和维护周期超过半年）
这里借一张图来说明：
横轴是复杂度，纵轴是生产效率。从生产效率的角度来讲，在两条曲线的交叉点之前，单体架构是占优势的，过了交叉点之后，单体架构的生产效率将大幅度下降。
所以很多专家和同行朋友都说，我们可以在开始的时候先使用单体架构，当业务发展到一定程度的时候，再重构成微服务架构。对于这一点，我是持保留意见的，因为在实践中，架构改造的难度还是很大的，会有一些问题，例如：
客户或业务部门是否给我们这样的时间窗口？
这段时间的研发经费是否有出处？
项目负责人或技术团队是否有主动的意愿进行架构升级？
项目负责人或技术团队是否愿意为架构升级带来的不稳定风险负责？
我们常常听到的一句话是：暂时先这样，等我们没这么忙的时候，再来优化一下。但是，绝大多数情况下，这一天 从来没有出现过。
再想想年初，我们的私有云平台经过 2 年多的发展，已经包含了容器服务平台（PaaS）、API 网关、监控平台、定时任务平台、数据库管理、用户权限管理等等十多个基础模块，也包含了一些为上层应用服务提供的日志服务、缓存服务、消息服务等等。并且，部署到了二十多个客户的生产环境里。可悲的是，我们支撑了很多的业务系统的微服务化，但平台本身任然是一个单体系统。
我们也深深地感受到了平台往前发展的阻力：
很多时候，客户需要的不是一个大而全的平台，他们希望按他们的意愿采购需要的模块。
新人进入团队后，从熟悉到动手产出的时间偏长。
其它研发团队有一些比较好的组件能满足平台产品的需求，却不能直接拿来用。
两个不同的模块之间产生了不该出现的耦合关系，导致意想不到的 Bug。
所以，春节过后，大家开了一个会，决定将平台微服务化。而带来的代价就是要说服老板给我们两个月时间来重构。
幸运的是，我们很快得到了老板的支持，并且重构工作比较顺利；不幸的是，那二十多个客户的生产环境的升级非常麻烦，每升级一个客户都得花上一周左右的时间，至今也才升级了一小部分。
所以，理想的情况下，我建议在项目初期的时候就从上面提到的三点做好评估，到底采用哪种架构形式是符合项目具体情况的。
当然，如果真的有朋友想将历史悠久的单体架构升级到微服务架构，我建议先从边缘逻辑开始，逐步逐步地将业务逻辑从单体系统里剥离出来。我没有这方面的经验，但可以想象，这将是一个非常长期和痛苦的过程。
那如何学习才能快速入门并精通呢？
当真正开始学习的时候难免不知道从哪入手，导致效率低下影响继续学习的信心。
但最重要的是不知道哪些技术需要重点掌握，学习时频繁踩坑，最终浪费大量时间，所以有一套实用的视频课程用来跟着学习是非常有必要的。
为了让学习变得轻松、高效，今天给大家免费分享一套阿里架构师传授的最新架构视频。帮助大家在成为架构师的道路上披荆斩棘。
这套视频课程，详细讲解了像（Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构）等这些成为架构师必备的内容！
而且还把Java需要用到的各种面试资料进行了打包，根据完整的文档系统的学习知识，让你在各类公司求职中无往而不利。
加群956058372 就可以马上免费获得这套价值不菲的学习资料！
最后，做一个爱思考，懂思考，会思考的程序员。
网友评论