首先，来自Darren的消息是，微服务架构并不是构建大规模企业应用程序的新方式。 Netflix和亚马逊等公司已经实施了微服务架构，在过去几年中提供了成功的产品。
但是微服务架构适合您的组织吗？答案不是简单的是或否，但我会尝试用Darren的讲话作为指导来引导你找到答案。
微服务架构是一个将在多个方面影响您的组织的旅程 - 在文化，技术和运营方面。让我们考虑一个跨国企业的单体应用程序，该应用程序已经成熟多年并占据了市场主导地位。从软件工程师或架构师的角度来看，简化代码库的复杂区域以使其更易于维护是一种很好的做法。
那么当你遇到一个疯狂的大型Java类时，你会怎么做，这些Java类包含许多代码行和一个不幸的方法，占40％的类？一个自然（和明智）的事情是与团队进行某种形式的讨论，并提出一种策略，将类分解为多个较小的类和/或方法。现在问问自己为什么清理整体Java类很重要？
如果您的答案是更简单的单元测试，更容易进行代码审查，更改影响，那么我建议您将相同的思维过程应用于构成产品的整体服务和模块。
将monolith应用程序拆分为更小，可管理的服务有几个原因。如果您是组织中的业务负责人，以下可能是您的一些担忧：
- 进入新市场
- 支持创新
- 在业务功能和系统之间创建更好的一致性
- 改变治理结构以更好地支持快速决策
- 快速响应新的市场条件
- 抵御市场颠覆者
作为首席技术官或首席架构师，您有责任评估最能解决上述问题的不同解决方案，并设计符合组织愿景的系统。以下是在考虑微服务架构时需要关注的一些关键领域：
- 多种服务之间的依赖关系管理
- 端到端功能测试的大小
- 快速检测故障，正常故障并快速恢复
- 容器作为构建工件
- 跨组织边界重用组件/模块
- 公共使用服务的API合同
- 监控部署生命周期的各个阶段
- 集中式架构团队与分散式架构团队
- 基建自动化
架构师的角色随着微服务的采用而发展，并委托他或她承担挑战性的责任，从而形成架构治理。架构治理是组织尝试开始微服务之旅的关键因素之一，因为如果没有正确的顺序，该过程将很快导致微管理而不是微服务。
将monolith分成多个可管理服务的最大优势之一是使一个小团队能够全面管理其服务的生命周期 - 开发，测试和推向生产。这意味着企业架构师不再需要承担单个服务的内部工作负担，而是高度关注整个系统中服务之间的交互。此外，架构师应密切关注系统的整体运行状况，以确保每项服务以一致的方式生成与监控相关的指标。
为开发团队提供完全的权限，以便在构建服务时选择他们选择的技术堆栈并不意味着架构师不再对其实现有任何发言权。事实上，架构师受到高度鼓励，可以教育和影响开发团队。例如，考虑到服务必须处理的数据的高度非结构化特性，架构师可以建议使用NoSQL数据库而不是关系数据库。例如，Netflix将JVM的使用标准化为一个平台，以便他们可以跨服务使用标准库。
虽然架构师之一忙于与开发团队合作，但另一个人正在与“业务”团队合作，以使技术愿景与业务愿景保持一致。这对于建筑师来说是一个重要特征，因为系统需要能够适应产品愿景或用户反馈的变化。因此，架构师需要始终掌握行业中的最新趋势，工具和框架，并准备好为给定的工作应用正确的工具。
Darren谈到了“部署耦合”的概念，强调了许多单片系统和传统企业架构需要在单个版本中将所有系统的更改同步到生产中这一事实。这反过来导致长时间运行的测试周期从未捕获任何东西，并且感觉没有人可以失败，因为一个系统未达到其截止日期意味着其他所有人都被推出。
通过使用远程调用作为集成服务的机制，可以避免部署耦合。微服务社区建议使用REST over HTTP而不是其他远程通信协议（如RPC或SOAP），因为基于非HTTP的协议往往会将您绑定到特定平台或对互操作性施加限制。通过基于用户级合同使用HTTP集成服务，开发团队可以避免永无止境的端到端测试阶段的陷阱并保持合适的速度。
然而，管理数百个服务会使组织的操作复杂化。作为一个组织，您必须确保拥有可靠的DevOps基础架构，以便处理应用程序监视和警报。正如我上面提到的，架构师必须至少标准化服务发出日志的方式，以便运营团队可以监控整体系统运行状况，并且如果需要进一步调查，则能够深入到服务级别监控。
最后，每个组织都必须努力招募，培训和留住高素质的技术人员，因为“微观团队”之间的沟通和协作需要有效，技术上的刺激以及最重要的乐趣是至关重要的！
我希望这可以解决你对大型企业中微服务架构的一些担忧。我鼓励你观看这个非常有见地的视频录制，其中Darren更详细地讨论了这些非常关注的问题。如果您正在寻找有关微服务架构的其他材料，请查看Martin Fowler的文章或ThoughtWorks网站上的其他微服务洞察博客。
