微服务架构师的取舍之道

微服务需要我们做出很多决定:应该使用多少种不同的技术、不同团队是否使用不同的编程规范、是应该合并多个服务还是把一个服务拆成多个。

架构师的职责之一是确保该系统适合开发人员在其上工作。他们需要保证系统不但能够满足当前的需求，还能够应对将来的变化。他们还应该保证在这个系统上工作的开发人员和使用这个系统的用户一样开心。

首先是做服务边界分区。作为架构师，不应当过多关注每个区域内发生的事，而应该多关心区域之间的事情。这意味着我们需要考虑不同的服务之间如何交互，保证我们能对整个系统的健康状态进行监控。很多组织采用微服务是为了使团队的自治性最大化，那么你会更多依靠团队来做出正确的局部决定。每个服务内部可以允许团队选择不同的技术栈或数据库存储技术。但事实上不会无限制地允许团队任意选择技术栈，如果要支持10种不同的技术栈，可能会在招聘上遇上困难。服务之间的事情更重要，如果不同服务采用不同的接口协议，那么对于服务消费者来说简直是噩梦。

其次，架构意味着在不同选择之间取舍。如果组织的战略目标是缩短新功能上线的周期，那么原则可能是交付团队对整个软件生命周期有完整的控制权。如果组织的战略目标是在其他国家快速增长业务，那么原则可能是系统能够方便地部署到相应的国家。原则最好不要超过十个，不然就很难记住，而且发生冲突和重叠的可能性会加大。通过技术实践如代码规范、日志数据集中捕获等保证原则能够得到实施。实践应该巩固原则。实践的改变频率高于原则。对小团队来说，可以将原则与实践合并。

第三，架构要提出要求的标准。监控:能清晰描绘出跨服务系统的健康状态非常关键。接口:选择少数几种明确的接口技术有助于新消费者的集成。架构安全性:必须保证每个服务都能应对下游服务的错误请求。没有能很好处理下游服务错误请求的服务越多，我们的系统就会越脆弱。返回码也应当遵守一定的规则。

第四，代码治理。范例:如果你有一些很好的实践希望别人采纳，那么给出一系列的代码范例会很有帮助。你的优秀范例应该来自真实项目，而不是专门实现的一个完美的例子。裁剪服务代码模板:针对自己的开发实践裁剪出一个服务代码模板，不但可以提高开发速度，还可以保证服务的质量。如果使用不同的技术栈，针对不同的技术栈都需要一个服务代码模板。服务代码模板不应当成为一个中心化的框架。

第五，技术债务。为了发布一些紧急的特性，你可能会忽略一些约束。这是另一个需要做的取舍。可以用技术债的概念来帮助我们理解这个取舍。理解技术债的层次及其对系统的影响非常重要。

第六，例外管理。例外可能转化为原则和实践。

第七，集中治理和领导。治理通过评估于系人的需求、当前情况及下一步的可能性来确保企业目标的达成，通过拍优先级和做决策来设定方向，对于已经达成一致的方向和目标进行监督。架构师承担技术治理职责。治理就是确保系统符合技术愿景，在需要的时候对愿景进行演化。架构师需确保同事理解这些决定和取舍，并执行下去。可以由一个治理小组来做这个工作，并确地愿景。

第八，建设团队。帮助你的队友成长，帮助他们理解技术愿景，保证他们可以积极地参与到愿景的实现和调整中。伟大的软件来自伟大的人。

演进式架构师应当承担的职责:

1、愿景:确保在系统级有一个经过充分沟通的技术愿景，可以帮助你满足客户和组织的需求。

2、同理心:理解你的决定对客户和同事的影响。

3、合作:和尽量多的同事进行沟通，从而更好地对愿景进行定义、修订和执行。

4、适应性:确保在客户和组织需要时调整愿景。

5、自治性:在标准化和团队自治之间寻找一个平衡点。

6、治理:确保系统按照技术愿景的要求实现。

​