微服务设计笔记（2）——从架构师角度来看待微服务
架构师职责确保我们的团队有共同的技术愿景，并向我们的客户交付他们想要的系统。需要协调多个团队，甚至整个组织内的工作。
1 城市规划师
其实架构师更像是城市规划师，需要做出一个允许变化的计划。
系统的使用者除了客户，还有开发人员与运维人员。所以，架构师要确保系统适合开发人员在其上进行开发工作。
架构师应该专注大方向，只在有限情况下，才参与到具体的实现细节中。保证这套系统，会让开发人员和客户一样开心。
2 服务边界
作为架构师，应该多关注服务边界之间发生的事。比如，不同的服务之间交互方式、监控整个系统的健康状况等等。
每个服务内部，允许团队选择不同的技术栈或数据存储技术。
3 规则
为了和目标保持一致，我们需要制定出一些规则。规则最好不要超过 10 个，这样大家才容易记得住。
通过规则来指定系统如何演化。还需要指导这些规则如何实践。
除了文档，还可以提供示例代码供人阅读、研究与运行。甚至可以创造出一些工具来确保这些规则能够被正确执行。
4 特性
4.1 监控
必须能够在系统级别，清晰地描绘出跨系统服务的健康状态。建议：让所有的服务都使用同样的方式来报告健康状态。
可以使用推送方式，让每个服务把状态数据推送到某个节点；也可以使用轮询方式，从各个服务节点，收集状态数据。无论哪一种方式，都应该保持一致。并且，每个服务内的技术细节，对外应该是不影响、不透明的。
4.2 接口协议
选择少数几种明确的接口协议，有利于使用者开发对接程序。还需要多多考虑，比如如何处理不同版本的 API？
4.3 安全性
确保每个服务都能够处理调用方所返回的错误信息。
5 代码管理
5.1 示例代码
因为开发人员更喜欢阅读与允许代码，所以提供示例代码以供模仿，是个好主意。
5.2 代码模板
依据优秀的开发实践，导出一些代码模板，不但可以提高开发效率，而且还可以保证服务质量。
如果组织内使用了不同的技术栈，那么每一种技术栈，都需要提供相应的代码模板。
可以通过合作的方式定义好这些模板，并根据需要及时更新。
6 破例
有时候，因为特殊情况，违背了初定的规则。首先，先记下来。如果发生了很多次，那么我们可以修改规则，来适应变化。
如果团队高度自治，那么这些规则只要把握好大方向即可。
7 管理
通过排优先级和做决策来设定目标，然后监督定好目标是否朝着良性方向发展。
架构师要确保有可以指导开发的规则，并且这些规则与组织的战略目标相一致。需要了解新技术，并知道如何在这些技术之间做取舍。还要让大家也理解这些取舍决定，并执行下去。还需要花时间与团队一同工作，甚至是编程。
组织讨论会，可以是与一个比较小的团队进行非正式沟通；也可以是与大团队进行正式沟通。讨论会必须要由技术专家领导，并要有一线员工参与。讨论的内容可以是之前说过的规则，以及跟踪和管理技术风险。架构师必须确保这些讨论会可以顺畅运转。
注意：即使架构师很清楚这样做是对的，然后为了避免团队偏离方向，不得不控制他们的行为。这有可能会破坏和团队的关系，让他们感觉没什么话语权。关键是知道什么时候可以这样做，什么时候不能这样做。
8 团队建设
架构师必须帮助团队成长，让他们理解团队目标，并积极地参与到这个目标实践中来。
机会成熟时，就可以给团队成员更多的责任，帮忙他们实现自己的职业目标。
架构师的职责总结如下：
- 在系统级别，输出经过充分沟通的技术愿景，通过它可以帮助我们满足客户和组织的需求。
- 了解所做出的决定，对客户和团队所带来的影响。
- 和尽可能多的人沟通交流，修订技术愿景。
- 根据客户以及组织需要，及时调整技术愿景。
- 在自治和约束之间，寻找出一个平衡点。
- 管理并监督系统朝着愿景的方向，稳步前行。
正文到此结束
热门推荐
相关文章
近期评论
-
你这基本没有更新呀，最近文章显示还是2019年的文章。不符合要求哈
-
关键词：慕云博客 链接：https://www.lilun.me 描述：分享原创文字的个人博客
-
-
-
可以提供一下源码吗
-
不是商业站，鸡娃学习笔记
-
-
-
-
听他们说很厉害的样子
Loading...
![[HBLOG]公众号](http://www.liuhaihua.cn/img/qrcode_gzh.jpg)
