了解微服务的流程和组织
我们已经谈过了微服务架构，现在来看看组织和流程。 01 进行软件开发和交付的组织 成功往往意味着研发团队规模的扩大。一方面，这是个好事，因为人多力量大。但是团队大了以后，正如Fred Brooks在《人月神话》这本书中提到的，沟通成本会随着团队的规模呈O(N ^ 2)的速度上升。如果团队太大，由于沟通成本过高，往往会使得团队的效率降低。想想看，如果每天早上的站会规模达到20人会是怎样? 解决之道是把大团队拆分成一系列小团队。每个团队都足够小，人员规模为8～12人。每个团队都有一个明确的职责：开发并且可能也负责运维一个或者多个服务，这些服务实现了一个或多个业务能力。这些团队都是跨职能的。他们可以独立地完成开发、测试和部署等任务，而不需要频繁地与其他团队沟通或者协调。
为了在使用微服务架构时有效地交付软件，你需要考虑康威定律，它规定了如下内容： 设计系统的组织……往往被组织的架构所限制，最终设计的结果是这些组织的沟通结构的副本。 ——梅尔文·康威 换句话说，应用程序的架构往往反映了开发它的组织的结构。因此，反向应用康威定律并设计你的企业组织，使其结构与微服务的架构一一对应。通过这样做，可以确保你的开发团队与服务一样松耦合。 若干个小团队的效率显然要高于一个单一的大团队。微服务架构使得团队可以实现某种程度的“自治”。每个团队都可以开发、部署和运维扩展他们负责的服务，而不必与其他团队协调。更进一步，当出现了某个服务故障或没有满足SLA等要求时，对应的责任人(团队)也非常清楚。 而且，开发组织的可扩展性更高。你可以通过添加团队来扩展组织。如果单个团队变得太大，则将其拆分并关联到各自负责的服务。由于团队松散耦合，你可以避免大型团队的沟通开销。因此，你可以在不影响工作效率的情况下添加人员。 02 进行软件开发和交付的流程 采用微服务架构以后，如果仍旧沿用瀑布式开发流程，那就跟用一匹马来拉法拉利跑车没什么区别—我们需要充分利用微服务带来的各种便利。如果你希望通过微服务架构来完成一个应用程序的开发，那么采用类似Scrum或Kanban这类敏捷开发和部署实践就是必不可少的。同时也需要积极实践持续交付和持续部署，这是DevOps中的关键环节。 Jez Humble把持续交付定义为：
持续交付能够以可持续的方式安全、快速地将所有类型的更改(包 （编辑：潍坊站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
