在之前的课程中，我们初步涉猎了互联网企业内分布式系统架构。在这一课程中，我们了解到系统架构需要演进。为什么会有这样的要求呢？在微服务架构治理与治理实践的课程中，我们详细微架构的相关历史和服务特征。以下是我的一些学习感悟和个人理解。
我们先要了解系统架构的演变历史：
首先是单体架构，它是最早出现的架构类型。它的优势有两点：性能最高、冗余小。而它的劣势在于debug困难、模块之间互相影响、无法进行分工。
接下来是垂直应用架构。它的优势在于可以实现业务独立开发维护。然而，它仍存在着不同业务存在冗余、每个业务还是单体，难以复用的缺点。因此仍不足以支撑大型项目的开发。
在垂直应用架构之后登场的是分布式架构。它成功的实现了业务独立服务。可是它存在着调用关系复杂，不同服务冗余的弊端，更会造成单个模块出现bug导致整个系统崩溃。
然后，SOA架构出现。它实现了注册服务,，但是仍未改变前几种架构的本质问题————中心化设计。这也就导致了项目必须自上而下设计，且重构十分困难。
演变至今，我们现在最常用的是微服务架构。它成功实现了高开发效率、业务独立设计、自下而上架构、故障隔离的众多目标。但是还存在着一些治理运维，以及安全性的挑战。
微服务架构的核心要素主要有三方面：服务治理、可观测性、安全。在实践过程中，想要完成治理的目的，就要从这三方面下手。在治理过程中，最常用的手段是重试，它可以避免偶发性的错误，提高SLA。更准确的说法是，重试可以降低错误率、长尾延时，容忍网络抖动等暂时性错误，并避开下游故障性实例。这和我们平时出现死机等一场情况选择重启是一个道理。因此，对于微架构而言，接下来最重要的研究方向必然是提高容错率。
